I was listening to Shop Talk show 287, where Chris and Dave were wondering about the old mantras about text-sizing / media queries not being in pixels, I think I can help with this.
I’m one of the many people working on WCAG 2.1, and specifically with people from the Low Vision Task Force (LVTF), most of whom are people with low vision (and very knowledgeable on the research for this group). There’s a ton of documentation being prepared, but I thought a little insight into this process would help, and perhaps a click-bait headline to help get it around?
First, let’s bust a couple of myths.
Myth: Pixels units for text are bad for accessibility
This was true in the IE5-6 era, where text-sizing was the main method of making content bigger. Technically it does still prevent text-sizing in some browsers (e.g. Internet Explorer) but the main issue is that text-sizing overall has very limited value. Not because re-sizing text is of limited value, but because doing so on 90% of websites will break before you get to 200% with overlapping-text or falling floats.
When I joined the LVTF waving the flag for responsive web design, there was some resistance to focusing on zoom & responsive as the main method for making things bigger, but there were two key points:
- The author (aka the designer / developer) can change the layout based on how much space there is. That means you can achieve a great deal more in the size of content.
- Zoom is the default (sometimes only) mechanism for people to make things bigger in browsers.
It is possible to deal with text-sizing with EMs and media queries, but then you have to size everything in EMs, including images and layout, which then mirrors zooming. At that point, you might as well use pixels and rely on zoom.
The Guardian is a good example of that approach, everything is sized in EMs so text-sizing works exactly the same as zoom.
Myth: Don’t use pixels in media queries
I’m fairly sure this came from a bug in Webkit which was fixed years ago. I don’t think there’s anything else to it, please add a comment below if you know of something.
There is no accessibility harm in using EM based media queries, but there is little benefit either, use them were it makes sense.
Do people really use user-stylesheets?
Yes, sort of. The mechanism of adding a user-stylesheet to your browser is very rare because one set of styles doesn’t work effectively across websites. However, extensions like Stylish are much more common (1.7 million users) as they can apply per website.
Current proposals for WCAG 2.1
There are currently three requirements for zoom/text sizing in WCAG 2.1 (which is due in 2018 and still subject to change). It has been a long process to develop these because sites have a million different methods of layout and sizing, and users with accessibility needs have another million methods for dealing with websites.
These are the requirements which we got to for providing the best-all around benefit to end-users whilst still being feasible:
You can increase the size of text size by 200%
The requirement from WCAG 2.0 will continue in 2.1:
1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
This means you should be able to resize content (it doesn’t preclude zoom) so that text is 200% bigger. It doesn’t have any requirement about horizontal scrolling, which makes it fairly useless these days as every site can be zoomed in. (Zoom wasn’t common when WCAG 2.0 was written.)
Reflow down to 320px wide
A new (draft) requirement in WCAG 2.1:
Reflow: Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels;
Except for parts of the content which require two-dimensional layout for usage or meaning.
This was originally formed around zooming, letting users zoom in 400% from a starting point of 1280px wide (which gets you to 320px). With this requirement people should be able to read things at larger sizes without having to scroll back and forth, and avoid missing things that are off-screen.
Note that not all content will have to increase by 400%. For example, if you have a really big heading at a desktop size, most sites will reduce the (relative) size of that heading for smaller screen (and therefore zoom-users). Having that be 400% bigger wouldn’t help anyone, and would look very odd.
We rely on the previous Resize text requirement to ensure that text does actually increase, so (for example) sizing text with VW units and not changing them across display sizes would fail. Not all text would have to increase by 400% (e.g. large headings that get smaller at small-screen sizes), but a lot would, and certainly more than 200% (with no horizontal scrolling).
Note that there is an exception for things which need to be “2D” includes images, video, data-tables and editing interfaces with toolbars.
Text Spacing
Another new (draft) requirement from WCAG 2.1:
In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
Exception: Human languages and scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are used.
This requirement is to allow people to over-ride styles with their own font-family, line-height and letter-spacing. This really comes down to: leave a little space around blocks which contain text, and don’t use fixed-height containers. If we can think of a testable way of doing it, changing the foreground/background color would be added as well.
This is far easier to do than allowing text-resize (not zoom) up to 200%, it equates to something like 115%. You also need to watch out for icon-fonts, as they tend to disappear when the user changes font.
So those three requirements together mean that people should be able to resize content more significantly than they do now, and override certain aspects.
If you’d like to comment on any of these, please do read the draft of 2.1 and head over to github.
You know I’ve long been an advocate for having true text sizing considered in WCAG – and this very well addresses this need, plus other considerations of user test styling. Thanks for your work on this!
I presume “Spacing underneath paragraphs” is so that if line spacing is increased there is also a mechanism to differentiate paragraphs. Paragraph spacing can be defined by authors numerous ways (padding, margin, etc. and on both top and bottom or a combination thereof). I can see testing this being a bit confusing. Would it be correct that setting paragraph bottom margin to double the font size would be a universal way to test this in HTML?
Hi Jared,
The paragraph aspect came from COGA rather than low vision, but I assume it helps most people differentiate paragraphs (i.e. walls of text 😉
Yes, I think setting margin-bottom to 2em would work well, you can see the basic script we’ve been using for testing so far.
Thank you for the reply.
Would non-differentiation of paragraphs ever be considered a “loss of essential content or functionality”? I wouldn’t think so.
My point is that you need to be careful to not conflate the focus of this SC to be about paragraph spacing for paragraph differentiation (the COGA focus). That’s important, but not the point here – which is if the user adjusts text styling – including paragraph margin properties (which could be used to ensure better paragraph differentiation) – that things don’t utterly fail.
I’m still struggling a bit with “spacing underneath paragraphs”. Is this only p tags? If yes, then changing p to div is a workaround? Is a one sentence div a “paragraph”? What about list items? This seems a bit nebulous – at least in need of a definition. Perhaps “spacing underneath blocks of text” or “spacing below text” is better?
Regarding the test script, this only really works if the paragraph text size is defined as 1em – which is very often not the case. It would be better to detect the text size and set the other properties accordingly.
Hi Jared,
I was hoping to keep it simple as ‘paragraphs’, but we have a definition for blocks of text if you think that’s clearer?
On the test script, I’m fairly sure that if you add 2em of margin, the starting text-size comes from the paragraph itself. I.e. if the text size of the paragraph is 16px, the 2em margin on the paragraph would be 32px.
Hi Alastair,
Thanks for the great post and your work with the LVTF!
I just wanted to note that changing the browser’s default font size does not affect text sized in pixels, only relative units. Here’s a demo page where folks can test this out:
http://output.jsbin.com/vogefucimo/quiet
For this reason, I still use relative units for font-size and media queries. However, I use a Sass mixin to convert px to ems so it’s no extra effort. You could also use PostCSS to automate it even further (e.g. https://github.com/cuth/postcss-pxtorem).
FWIW, I also use a mixin to allow me to scale up the font-size as the viewport width increases to maintain an ideal line length.
https://threespot.github.io/frontline-sass/documentation/#main-function-fs-scale
Also, I just checked the Guardian’s homepage and there are only a handful of pixel values, everything else is em/rem. Where were you seeing the fixed pixels?
https://assets.guim.co.uk/stylesheets/386d4df294cb1fe57f3deb9d6aa8bae5/facia.css
Hi Ted,
Yep, using pixels can defeat some methods of changing the browser’s text-size starting point. However, my point was that it is easier to manage with zoom anyway.
I brought the guardian up as an example of a site that uses (almost) all EM / font-relative units, therefore text size is just the same as zoom.
In which case, there is no difference and you might as well use pixels, and users just use zoom.
Ted, note that scaling text with viewport size (even when using calc() to create a buffer) can mess with some users’ desire to scale a viewport as a way to get more or fewer characters on a line, or more or fewer lines of text in a viewport. Short viewports can really be hampered by this. This is based on testing. YMMV.
Thanks for sharing Alastair! I’m curious if the LVTF has any data/stats on whether or not (and what percentage of) low vision users make use of the browser based text size settings. The fact that text size (not zoom) settings persist across browser tabs and sessions made me assume that low vision users would prefer that method over text zoom, but that’s just an assumption.
Hi Jeremy,
I can ask, but I know WebAIM did a survey in 2013, and more used zoom then than text-sizing at that time (as reported in the AT section). As zoom works better with responsive design (which is becoming more common) I’d assume that percentage will go up over time.
I’d also point out that in several browsers (Chrome and Edge that I have to hand) the zoom is persistent (or can be) as well.
Jeremy, Alastair—Yes, would also love any recent stats on zooming vs. default browser text size!
Alastair—Gotcha, thanks for clarifying! I’m afraid still not clear on why using px would be better than relative units, though. Even if most people zoom, shouldn’t we still try to create a good experience for those who change the browser text size?
Adrian—That’s interesting, thanks! Can you provide any more details about your testing? What line length did you find worked best? Viget did some testing back in 2009 and found ~100 chars/line worked best.
https://www.viget.com/articles/the-line-length-misconception
Hi Ted,
I didn’t say it one was better, just that px aren’t bad.
If a user adjusts the text-size, that is harder to manage than zoom. Text sizing often ends up with overlapping text or dropped floats.
You then think “why don’t use you EMs and media queries”, which you can, but then the effect is the same as pixels and zoom.
From what I remember (from the same old research, but based on human perception so relevant until proven otherwise): there is no perfect length, but it’s best to allow some control.
I think Adrian’s point was that you’re taking away people’s control. (Inevitable to some degree, but “scale up the font-size as the viewport width increases” really locks it.)
Ok, I get where you’re coming from, thanks for explaining.
Re. scaling up the text size automatically, I don’t think of it as taking any control away from the user, since people can still zoom in/out.
I first learned about this technique from this Trent Walton post http://trentwalton.com/2012/06/19/fluid-type/ and have seen many other sites apply it. Not saying that’s proof it’s the best technique, but I haven’t heard anyone saying it’s bad for accessibility before. Would love to hear any opinions to the contrary 🙂
The idea of allowing the user to control the line length is interesting. I’m not entirely sure what the best way would be to do that, other than not setting a max-width on the content well. I suppose if you zoom in enough, you would get the mobile layout, but then the text would be really large. Do you have any examples of websites that allow people to control the line length?
Also, thank you all for taking the time to discuss these issues, it’s much appreciated! I’m currently working with a client who has a large blind/partially-sighed audience so want to make sure I’m following the current a11y best practices re. text sizing. FWIW, we’re also planning to include a text size and color theme chooser, like on http://www.bbc.co.uk/accessibility/
Well, allowing the user to vary window size (at the preferred zoom level), between about 40 & 110 char wide.
I’d say there are other factors that are more important, this is on the nice to have side.