Is text sizing dead?

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:

  1. 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.
  2. 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:

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:

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.