Denis Boudreau and Wayne Dick presented on why browser zoom sucks, firstly from the point of view of testing with WCAG, and then from a low-vision user’s point of view.
The are on slideshare.
Resize text criteria (Denis)
At Deque they have discussed and mulled over success criteria 1.4.4, resizing text, and they don’t agree internally! (AC: This has also been an issue at my company.)
One of the specific aspects is the example where the W3C says that horizontal scroll bars are ok, so every site passes! Denis was struggling with the argument that text-sizing is still needed.
Denis is agnostic about the technology aspect, his preferred definition of that was: does not deliberately favor specific web technologies
– Jared at webaim.
Denis sets up the argument (in boxing terms), where:
Web developers want easy solutions, reliable testing & measurable results. Therefore they like browser zoom.
Users was robust solutions, adaptive interfaces, usable content. Therefore they like text resize.
(AC: I disagree with this premise if you are using Responsive Web Design (RWD), but they get to that later.)
The user base for low vision from world health organisation stats is: 285 million people with visual impairments, 39 million blind, 246 million have low vision (7 times as many).
Denis picks (on) the the Financial Post to test zoom, which at 200% zoom produces a lot of horizontal scrolling. That is really annoying
(AC: Wholeheartedly agree!)
With text zoom the experience is better on this site.
(AC: I did notice later that the navigation is unusable though.)
Low vision user – Wayne’s section
Wayne comes on to introduce things from a low vision point of view.
When you started with Guttenberg, the print was pretty big! But as the technology got better and you could make smaller print sizes, it got smaller and smaller. It didn’t keep shrinking though, it came down to a certain minimum. The “critical print size”.
That created a normalisation of text for the “common reader”.
Is zoom bad for everything? No!
- Zoom is great for spot work near the acuity limit.
- Small control forms can be zoomed and operated.
- (AC: there was another couple, but I missed them.)
Low vision users generally keep things as small as we can cope with, and then focus on things to zoom in.
One of the things about low-vision is the variety, a friend with a similar condition couldn’t stand Wayne’s methods of coping, it would make him puke!
Enlarged content presented for users with full sight is not the same as content presented for people with impaired vision. (AC: I didn’t quite get what this meant in practical terms, can anyone add a comment about that?)
The lack of word wrapping when zooming creates “semantic discontinuity”, i.e. the words don’t proceed in order. The meaning should follow continuously down the page.
Basically, panning when reading really sucks.
Questions / My thoughts
At this point responsive web design (RWD) comes up, and it was essentially considered the future, although with caveats.
Denis mentioned our previous blog articles on this (his and mine).
After a few questions on that subject, there was general agreement that horizontal scrolling really sucks and the guidelines should account for that (more). When WCAG 2 was created 200% text-sizing was quite difficult to achieve. With RWD now I don’t think that’s a problem, for a 1024px wide screen zooming in 3 times means you get a mobile-sized version (300px wide). Most sites test RWD down to that level, so it should work.
Shawn Henry was in the audience and mentioned that it could be something that is updated in a future version of WCAG (or the associated documents).
NB: Recent stats show that around 12% of the top 10,000 sites are responsive now. I suspect most site re-designs are going to be RWD from now on.
Personally, I will put forward my proposal when SC 1.4.4 comes under review again.
What probably does need more discussion is how zoom on mobile works. For example, an RWD website does not re-flow when you zoom in, it is like desktop-zoom without RWD.
Hi, Alastair! Thanks for these blog entries about CSUN14, as I was not able to make the conference this year. Having taught from Wayne’s experience, I can help you explain how enlarged text for people with full vision is not comparable to accessibility of text to people with low vision.
Those of us with full vision:
Usually use magnification only rarely.
Generally use magnification for only for brief periods.
Have the luxury of being able to remain at a comfortable distance from the screen as we enlarge the text.
People with low moderate vision:
Use magnification almost every time they interact with their monitor.
Must use magnification for extended periods—for example, for as long as it takes to read this post and my response.
In addition to using magnification, must also get very close to the monitor to read.
This reality makes our needs opposite in two respects:
Whereas high contrast helps people with full vision read better, low contrast is essential for people with low moderate vision.
Remember Wayne’s chart showing the critical print size? If you recall, that was the left end of a plateau in the plot of reading speed versus font size. The way to exploit that plateau is reversed for the two populations.
Why does low contrast help people with low moderate vision? Hold your face against a bright white screen (or a black screen with white text) for 60 seconds and see if you don’t get a headache. Now imagine having to read that way for hours a day every day of your life.
That’s why the customized color schemes Wayne showed you had very low contrast. If I recall correctly, the combination most comfortable to Wayne has a luminance contrast ratio of 1.3:1. (The combination preferred by the friend who finds Wayne’s combination nauseating is actually lower—1.1:1.)
In the plateau of comfortable font sizes, it has made the most sense to keep text at or just above the critical print size for people with full vision. That has reduced the amount of paper needed for any given publication. For headings, the larger fonts within the comfortable reading range can be used. They don’t have as many words as the running text, so even when magnified they don’t use up much paper.
But for people with low moderate vision, it makes more sense to have the running text a bit larger than that critical print size. That way, you can make the headings smaller—right at the critical print size—and still have them be readable. How do you make the headings stand out? Change the color scheme. And how do you differentiate levels? Make the color scheme unique to each level: Red background is h1, yellow background is h2, green background is h3, and so on. They can all be the same size, because the color scheme distinguishes them. Or they can be formatted as an outline: Roman numeral, heading 1; capital letter, heading 2; arabic numeral, heading 3; and so on.
Obviously, it all depends. Wayne has to be able to use his color scheme; his friend has to be able to use hers. People with low moderate vision who can see the full color spectrum could use the color-coded headings; other people would have to use outline numbering to distinguish heading levels. There is no way a Web developer can build this functionality into their site.
Fortunately, they don’t have to. If they can just ensure that the text doesn’t run off the screen on magnification, then the browser will let the person using it do the rest: a personal stylesheet will supply the fonts and color schemes that make the text readable to them. Teaching people with low moderate vision to create such a stylesheet should be as common as teaching people who are blind to use a screen reader.
And you know what else? When time comes to reconsider WCAG 2.0, we should add a success criterion at Level A: “Foreground and background colors, font selections, and font sizes are assigned with a stylesheet that can be overridden by the user agent.”
Think about it. What’s more important—making sure the users can adjust the presentation to meet their individual needs, or coming up with a design that meets any given (and somewhat arbitrary) lower threshold for a luminance contrast ratio and parameters for text size?
I’d go with letting the user choose—every time.