An article from Evan Minto did the rounds on Medium a while ago: Pixels vs. Ems: Users DO Change Font Size, and I posted a couple of comments which I’d rather didn’t disappear so I’ll summarise them here:
I don’t dispute the data, which showed around 3% of visits didn’t use the standard 16px default text-size setting. However, do question the conclusion, in terms of what we should do about it (i.e. convert everything to EMs/REMs).
The user has the choice to change various settings, including text-size, zoom, and more. In desktop browsers, zoom is either the default, or the only setting for making things bigger.
On mobile it is different, iOS doesn’t have a setting for text-size (that affects websites), android does but it’s limited. Everything can be pinch-zoomed, but there is no good option for ‘reflow’, where the layout adapts to the zoom-level or text-size.
Update iOS Safari now has the ability to set a zoom level. It is obviously more limited than the desktop option as you are starting with a smaller screen, but it works in the same way. I.e. pixels get bigger.
As developers, there are infinite options in how things are sized, but key ones are how text is sized, and what the layout is relative to.
For sake of argument, assume everything on a site is set in EMs (text, layout media queries). In which case, on a desktop browser everything works exactly the same as zoom. (The guardian site works like this.)
What is gained?
If you set everything in pixels, a some people won’t be able to resize it in certain browsers, but if you need to resize text, then IE is not the browser for you (unless you go into the setting and allow the override of site styles).
Resizing affects people with low-vision the most, and I’ve worked on this with the low-vision task force at the W3C/WCAG. There were two key requirements that were converted into criteria for WCAG 2.1:
- The ability to make things bigger but keep it within the viewport. (Reflow)
- The ability to adjust fonts and spacing. (E.g. override the font-family, add to letter spacing, text-spacing)
As developers it is really difficult to deal with text (only) increasing in size, in the 2008–2010 era before media-queries, meeting WCAG 1.4.4. “Resize text” was really difficult. Your layout had to cope with hugely increasing text size without media queries.
Post-media query support it is not difficult, if the units work together.
Things to avoid are:
- Mixing layout units, e.g. EM widths with PX media queries.
- Tight tolerances for text within layouts, text needs a buffer in cases where it cannot wrap.
There is probably more I can’t think of right now, but if you test with the guidelines in mind, that’s a good indication of meeting the user-need.
Evan replied (yesterday):
This is great feedback Alastair! Sorry for the delayed response.
I think it’s really useful to think of it in terms of those guidelines you mentioned (I preach the bit about not mixing units to devs all the time).
But there’s also a risk of relying entirely on browser zoom to achieve them. While, yes, that would satisfy the WCAG criteria (if I understand them correctly), it seems like a pretty bad user experience to nullify a semi-prominent feature like the font size setting in browsers. When users change that setting, they should be confident that the font size on websites will change. Maybe borders or rounded corners or other visual features won’t change, but font size should for sure (and based on the WCAG criteria, layout as well, to avoid overflow).
I think there’s a misunderstanding about where the guidelines come from.
Let’s start where we are likely to agree: The goal is that a user can adjust the size of content on any website to their preference and make full use of it.
The question is then: How do we get there?
The Low-Vision task force (which is primarily made up of people with various forms of low-vision who work in the field of accessibility) worked through the requirements, from the current research and personal experience.
The range of size some people require (starting with a default text-size of 12–16px) is from a bit (e.g. me without my glasses), to somewhere in the 1000% range (i.e. over 100px tall text).
The data you’ve picked up from text-sizing preferences skews low in text-size terms. In the UK (similar to US) there’s about 3% of the population with a visual impairment (which cannot be corrected to 20/20 by glasses), most of whom would need more than 20px sized text.
My guess about why that is the case is: Text-only sizing simply doesn’t work beyond a small amount.
If you try text-only sizing on pretty much any site, there are two outcomes:
- Text breaks out of the containers and becomes unreadable (like here on Medium, try expanding text and reading the related article boxes).
- Layout is sized with text-based units (EMs/REMs) and therefore works the same as zoom.
Only very simple (e.g. 1 column) sites really cope with text-only sizing well, and even then there are issues with ‘cards’ or boxes.
The new WCAG criteria come from this experience: In practice text sizing doesn’t work well enough because there is no (reasonable) mechanism for developers to adapt a layout as text (only) expands. (Again, you can size everything in EMs, but the effect is the same as sizing everything in PX and using zoom.)
Given that zoom & media queries allow for a much greater range of sizing, and it is reasonable to expect designers & developers to use them, it is the better option overall.
Evan replied again:
Thanks for clarifying. It sounds like the point you’re getting at is that accessibility isn’t a point in favor of rem/em since pixels achieve the WCAG criteria just as well. I hear you on that, but if that means developers should be free to use pixels, where does that leave the font size option in browsers? Should devs treat it as deprecated or something? I’m not super comfortable with an approach like that, since it seems like it forces users with custom font sizes to switch to using zoom (unless I’m missing something).
Also, I don’t think the choice is between purely relying on zoom (i.e. using pixels) and emulating zoom (i.e. using ems/rems). There are ways to use a mix of both to account for different needs, especially now that we have things like calc(), Grid, and the upcoming min(), max(), and clamp(). I think Jen Simmons has talked about this a bit in a different context, the idea of mixing units in “intrinsic” web design.
> “accessibility isn’t a point in favor of rem/em since pixels achieve the WCAG criteria just as well.”
Since pixels don’t impact the user-need (as that’s where the criteria come from).
> “where does that leave the font size option in browsers? Should devs treat it as deprecated or something?”
Browsers are, have you tried finding it recently?
> “it forces users with custom font sizes to switch to using zoom”
Having worked through that with quite a few people (low vision and accessibility advocates), that is already happening, and once switched, it is a much better experience in the majority of cases.
Also, have you tried supporting increased text-size beyond 150%? You very quickly get to a point where you need to change the layout to accommodate the increase, it’s just physics. At that point, the unit is not relevant.
I’m not saying “use pixels”, I’m saying that it isn’t an accessibility issue to do so.
When you get down to it, pixels are the best cross-platform unit of measurement because it is defined as an angle, and the manufacturer/browser decides how big a pixel should be based on viewing distance.
The rest is CSS management.