rems and ems, and why you probably need them
The holy “px vs em” war wages on. But it never should have started. Not because one side is absolutely correct, but because these design decisions should not be reduced to binary. It’s not all or nothing or one or the other.
This is a response to David Gilbertson’s rems and ems, and why you probably don’t need them post and addresses each section in order.
It’s definitely better for accessibility
David writes:
My point: you don’t need in depth knowledge and fancy tools for working out if rems and ems are ‘better for accessibility’ — just imagine that you are someone with bad eyesight
This may be well intended but is ridiculous advice nonetheless. You can’t just “imagine” disability. Abled developers making naive assumptions about what a disabled person would want is how we got into this mess. The fact remains users expect to be able to increase font sizes using the user agent, not just browser zoom. Need proof? Survey visual impaired users asking they if they’d appreciate a website responding to their font–size preferences, not just “browser zoom”.
As an abled person, don’t put yourself in the mindset of a disabled person. You can’t. Instead engage with disabled communities, ask them questions, hire them for usability testing and consulting. Listen to them; don’t just imagine you are disabled and proceed to speak for them.
David writes:
I don’t know about you, but if I had trouble reading small text, I’d bump up the default font size for the OS and forget about it.
He’s right. We don’t know about our users, which is why we should avoid these assumptions like they are tabular layout. Web pages that set font size in pixels do not respond to font size preferences such as those found in Google Chrome, the most popular web browser. But we can assume that they can use operating system settings instead right? Not exactly. Keep in mind that for a variety of reasons users might not even have access to operating system level settings. I know I didn’t when I was studying as a visually impaired design student in computer labs. Or at the local library.
As web developers it is not our job to assume what users will or can do. We should respond to and support their accessibility preferences in any and all areas for an inclusive and world wide experience.
David writes:
Although we have no evidence as to whether or not people rely on changing their browser text size
The use of assistive technology doesn’t show up in Analytics Dashboard but that doesn’t mean there is no evidence to be found. Expand your perspective beyond developers who, drunk on practices that favor themselves over end users, pat themsleves on the back for malpractice. Go to an accessibility conference, or a meet up, and talk to visually impaired people. Gather evidence by engaging directly with the disabled community. Don’t expect their sensitive accessibility preferences and health information to be tracked online.
The above facts, to me, make it crystal clear that browser text size adjustment is of no use in the real world. And so I will not take this setting into account in my decision making process.
This is an assumption that seems to have been made without consulting the visually imparied community or acknowledging the existence of User Stylesheets so I will not take this assumption into account in my decision making process and neither should you.
There is a misconception that because browser zoom will scale font size now we don’t need to worry about font size preferences anymore. It is important to understand that browser zoom and font size preferences are two fundamentally different things. Similar to pinch zoom on a mobile device, browser zoom scales the entire interface. Whereas the design is scaled with browser zoom and either introduces horizontal scrolling or adapts by responding to breakpoints and adjusting layout, font size preferences only increase the size of text and relative units — not the entire interface. Users with motor disabilities may be more inclined to zoom entire interfaces, increasing the hit areas of clickable elements, while visually imparied users may enjoy the ability to only increase font size and related relative units.
Breakpoints scale when you use rems/ems
In this section David points out that modern browsers will scale pixels along with browser zoom. Browsers did not originally to do this. In response to the rampant misuse of declarative pixel units browsers made a breaking change to how they interpret CSS units. Make no mistake, if all web developers used CSS in accordance with the CSS specification and accessibility best practices, browsers would not have made this change.
Now that browsers forcefully scale pixel units, designers have actually lost the capability to declare that “no for reals, this text should always be 10px even when the browser is zoomed or font size preferences are adjusted”. In other words, we can’t declaratively set type anymore. Why would a designer want to do this? Type isn’t just used for legibility; it is also used as illustration and texture. Thanks to rampant misuse of CSS units, designers no longer have the capability to size HTML text declaratively as illustration or texture as they did before.
Use ems for ‘dynamic’ spacing around text
David acknowledges the fluid nature of relative units:
This is almost a good idea, I see where the proponents are coming from. “Why change font-size and padding, when you can use ems for the padding, then only change the font size?” they say in their outside voice.
Prior to citing his own personal preference:
I just prefer…
There it is folks — the underlying misprioritization that got us into this mess. Somewhere along the line we started putting ourselves at the center of our designs, but it’s not about us; it’s about our end users. A responsible web architect does not values their own personal preferences over inclusive design pattern and accessibility best practices. Imagine a builder explaining to a home buyer, “you know, the building code states I should set studs 16 inch on center so the house doesn’t cave in on your family during an earth quake, but I just prefer 24 inch on center. Much easier to work with.”
Allow your visitors to use familiar and standardized practices to control the legibility of their experience. And don’t justify poor practice with common usage. Flash was popular once.
Make modules that you can resize simply by changing the root element font-size
I can’t recall the last time I wanted a component that grew in all dimensions, paddings and font-sizes, by the same factor, by changing just one value.
Ok. But again, this isn’t about you the developer. Ask your audience if they can remember the last time they wanted to use the user agent to be able to control the scaling of components on the page. And remember that if there is a lack of disabled representation within your audience that may be because the design isn’t inclusive to begin with.
Setting type and layout declaratively because you don’t want to do math or whatever may benefit you as a developer. Does it benefit your users in any way? No. Does it lessen their ability to control the legibility of their experience? Absolutely. The experiences you design should revolve around your users — not you. They’ll still be using the experiences you create long after pack up your tools and leave the job site.
Imagine an architect saying “You know, I can’t recall that last time I needed to use brail in the elevator. Let’s leave that out”. There are probably architects that don’t enjoy designing around accessibility requirements but I’m sure we can agree it would not only be ridiculous, but illegal, for them to favor themselves over the needs of an inclusive society. And the web should be no different.
You can scale all the text on your page with one property
David demotes the notion that anyone would want to scale components flexibly:
It assumes that you want to increase/decrease all text on your site at the same time for a given breakpoint. Headings, menu items, body text, all at once, all by the same factor. Now that’s courage.
That is literally exactly what a visually impaired user would expect when setting something like the following CSS in a user sheet for your web site.
#thing-i-need-to-see-better {
font-size: 200%;
}Please. Stop making your design decisions about you and start making them about what your world wide audience expects.
In conclusion
David concludes:
I think it all boils down to this: there are times when you should use rems and ems — they’re in the spec for a reason.
Amen brother. He continues:
So don’t go looking for a reason to use ems and rems. It is enough to what they do. Use pixels, and if a scenario pops up where ems or rems are the better tool for the job, go for it.
It’s not about you looking for reasons to use, or to not use, a tool based on you as a developer. End users don’t care what CSS units any of us prefer or why — base your decision making on end user experience and working towards a more world wide and inclusive web for everyone.
David makes some valid and noteworthy points on why relative units are less critical today than they were years ago. It is certainly true that ten years ago you wouldn’t of been able to get a job writing CSS if you set type in pixels, but today you’re Senior Developers will probably be not only be setting type in pixels but doing so directly in JavaScript. Which inclusive design patterns you decide to use is ultimately up to you, but please don’t buy into the myth that all you need to do is put on your “disability thinking cap” and imagine yourself as a disabled person to make design decissions on their behalf. We’ll never architect a web for everyone that way.
ps: Don’t take it from me. Take it from CSS spec authors.
