This post was motivated by Denis Boudreau’s Why Browser Zoom Testing Sucks for Accessibility, even though I disagree with the conclusion, it makes some good and important points and it will help set the context for this post.
It’s one of several posts recently talking about ‘text sizing‘ (where only the text of the page changes size) is necessary, as well as (or instead of) ‘zoom‘ where all content is scaled up.
I consider text-only sizing a non-issue for new projects for three main reasons:
- All desktop browsers default to zoom, and regular people generally use the defaults.
- When you are making or testing a responsive design site, zoom works better than text sizing, a lot better. The media queries trigger as though you were using a smaller screen, and everything re-arranges to fit the ‘smaller’ screen size.
- Allowing for either text-sizing or responsive is complex enough, doing both maybe impossible for any but the simplest sites. Given that responsive sites are better for zoom, lets focus on making responsive techniques accessible to all.
Defaulting to zoom
IE has had zoom in the visible browser chrome since version 7, and a decent zoom feature since version 8. Opera and Chrome have always defaulted to zoom, and I’m not sure when Safari switched to zoom by default but it was some time ago.
As a user you actually have to know:
- that there is another option,
- what difference it makes, and
- how to enable it.
Some people I’ve tested with weren’t sure there was a way to ‘make things bigger’ at all, most knew the default (e.g. “I press cntl and plus”), and those that new about the text sizing option sometimes used it, sometime not.
Mobile browsers have different criteria, they already do ‘zoom’ for non responsive sites, a few do allow for increased text size, but it doesn’t tend to work very well.
Responsive sites
For me this was the missing factor in Denis’ post, as zoom works differently for responsive sites. Frankly, I would agree that zoom (testing) sucks if this weren’t the case, but 90% of the sites we’re working on these days are responsive or will be responsive in the next iteration.
I generally take a two step approach for testing WCAG2 1.4.4:
-
Resize the window to around 1024px wide, something on the low end of current desktop/laptop resolutions.
Zoom into 200% (which is 5 times cntl + in most browsers).
If the page is responsive and it re-flows well, pass. If not, move onto step 2.
-
Try text zoom, and see how much breaks.
If you loose content or functionality, fail.
It’s a bit of a new way / old way, switch. The funny thing is, the type of sites that haven’t gone responsive are unlikely to do things that work with text sizing either. If they care about robust front-end code, they are probably going to put that effort into a responsive design, not fiddling around with container units.
It is probably a bit harsh to say the horizontal scrolling is a fail at 200% zoom, but if you factored that in, I think it would solve Denis’ issue?
Here’s a quick example with the Boston Globe with text sizing on the left vs zoom on the right, both at 200%:
I think you’ll be hard pressed to find any moderately complex site (e.g. with multiple content columns) that works well with text zoom. None of the sufficient techniques for SC 1.4.4 would prevent overlapping text on a complex site unless you use media queries. When you make things bigger, something has to give.
Inflection point
I agree with Denis’ points about how important it is, but allowing for text-only sizing isn’t the only, or even best way to do it.
I think we’re at an inflection point, as responsive designs become the norm, the zoom approach works very well for those sites as it re-flows the content properly, in a way the developer intended and tested for anyway (because they test on mobiles). Zoom is also the method that regular people use by default, so we’re making the default method work properly.
If we (as accessibility advocates) insist on text sizing, that’s adding a heap of extra variables to test, and it won’t happen. Let’s slip-stream the responsive bandwagon and make sure that responsive techniques are accessible.
Update
Denis and I have continued the conversation on twitter, I acknowledged that not all (or even that many) sites are responsive (yet), and Denis acknowledged that if zoom and responsive design proves robust it is a viable alternative.
What we really need is examples, do you know any good responsive sites? Or sites that work particularly well for expanding text? Please post below and we’ll check them out.
Any site with columns who wants to work with text zoom need to have floats or something who always contain their contents (so, long words) and do the usual float-drop so that you end up with a single column eventually. This can be at odds with some responsive designs and many of us have fled to inline-block for m0aR jawsomeness.
Re the note about “most people use the defaults”… well, most people don’t use assistive technology or adjust their browsers to suit any special preferences or disabilities, but those who do are the ones who would be most concerned about text-enlargement vs zoom, don’t you think? While many more users would certainly benefit from knowing how their browsers work and certainly many who need to know this stuff don’t, the question is “Are we testing these people?” Maybe most WCAG criteria don’t apply to me, for example, or maybe not even a majority of people, but that’s certainly never been an excuse or reason not to do tests.
Zoom will become more acceptable when it stops making blurry images. Possibly this could come from the responsive-images working-groups or someone else, but if you ever once worry about people getting headaches and blurred vision from flashing things, how could one not worry the same about people trying to read clear sharp text next to blurry images? I use text-enlarge specifically so I don’t have to hold my hand up to the screen to cover the image.
My views can be summarized by the following points:
1. Many low vision users use zoom or use a screen magnifier.
2. No sites break or fail WCAG when using zoom.
3. Some low vision users increase browser text sizes.
4. Most sites (and nearly all web applications) break and fail WCAG when increasing text sizes.
5. Users that need very high levels of zoom (generally >150%) use zoom/magnifier, not text sizing.
See http://webaim.org/projects/lowvisionsurvey/#at
Our clients have found that supporting WCAG’s 200% requirement via text sizing to be extremely burdensome and difficult (often more so than captioning). Telling authors that they must entirely restructure and simplify their application (often making it worse for almost everyone) to meet the needs of almost no users (see #5 above) is not beneficial to accessibility efforts and certainly goes against the spirit of WCAG.
On the other hand, authors need do nothing to meet WCAGs 200% requirement using zoom. But what then of the users that do use text sizing?
The solution (though not perfect) is pretty simple. Authors should support 200% zoom (congrats, everybody passes) and perhaps 150% maximum text sizing. This approach 1) meets the WCAG requirements, 2) addresses the needs of the vast majority of low vision users, and 3) does not impose an excessive burden on site authors.
Stomme: On defaults, I’m basing that on usability testing with people who have low vision and use their browser controls.
They tend to know the “make things bigger” controls, but very few knew there was a text-specific variant.
I’m not trying to split audiences, I am assuming (based on some evidence) that low vision users are regular people to!
On images, I agree that clear images would be good, but larger image is hardly worse is it? So long as they don’t get in the way (which is easier to deal with in RWD).
Jared: Yea, I’ve had similar experience, for years we were doing liquid layouts that (tried to) meet that, it’s hard.
I’d be very interested in asking about this in your next low vision survey, assuming you do one?
One question would be about whether they use their browser to make things bigger, and another one whether they use zoom or text-sizing.
From experience, not that many people know the difference, so you need to be careful about how that is asked.
I know it isn’t strict WCAG, but I tend to count horizontal scrollbars when zoomed at 200% a fail unless text-sizing is supported.
WCAG 2 was released before media queries became well supported. There should now be 2 methods to pass:
The first of those is more achievable for a new project, the second is essentially the non-responsive / legacy version.
The normative text could be interpreted as that if the examples were adjusted.
Would that make sense to you?
The survey did ask specifically about browser zoom and browser text sizing. And users that used browser text sizing do so at much lower levels than users of zoom or screen magnification.
I’d generally agree with your 2 methods, except I’d maybe structure as:
Level AA
– Zoom at 200%
– Text sizing at 150%
Level AAA
– Zoom at 200% with no horizontal scrolling
– Text sizing at 200%
One reason those who use text sizing don’t enlarge as much, besides pages breaking, is the browsers who offered it generally had a limit. Zoom may have once also had a limit, but today in two of my browsers the zoom seems to have no end. Those who need screen magnification generally cannot reach the sizes they need with text sizing.
quote:”but larger image is hardly worse is it?”
They are terrible. Moving my eyes back and forth around sharp text with something blurry next to that text gives eyestrain and sometimes vertigo. There are times where I deliberately enlarge an image to try to pick something out, but by default I’d rather they remained small and sharp (again unless there’s another possibility).
Most people don’t seem bothered by flashing things either.
Jared’s suggestion of two levels based on zoom or text enlarge do sound sensible.
I guess it’s a matter of scale, text-sizing only works up to a certain point (sometimes capped by the browsers), zoom scales further.
On large (blurry) images, we are battling bandwidth issues as well so it’s a harder problem that probably won’t be solved until picture / srcset are sorted out and we can declare multiple images.
Out of curiosity is this issue due to visual impairment? I might (naively) assume that if someone needs to enlarge text, then their vision is not very good, and therefore blurry images are not an issue.
With a mild visual impairment that’s how it is for me, I can barely tell that the images are not crisp unless they are images of text.
As we discussed over Twitter, I can agree that on some (most?) responsive websites, page zooming seems to be a viable option as long as zooming happens in the current width of the viewport. In other words, the page zooms without creating a horizontal scrollbar – which does sounds like a positive thing for the word wrapping issues I described in my blog post. That might solve the reading flow issue low vision users experience some (most?) of the time, when reading short paragraphs of text or text that spans over a reasonable portion of the viewport, but I’m not convinced it solves the issue when text is organized into columns.
While some quick testing these past few days have shown that horizontal scrollbars usually don’t happen on truly responsive sites (potentially settling that issue), one thing that does happen (and quite a lot as one would expect) is that once page is zoomed, some of the text ends up being lost because it overflows its intended area or gets truncated because the container its in just isn’t big enough to contain it anymore. Granted, we get the same behaviour with text resizing, but goes to show that RWD websites are not the panacea for low vision users either.
So while I can admit that some of word wrapping issues might be handled on truly responsive sites (user testing is going to be required), I also believe that truly responsive websites only account for a small minority of websites out there today (the tip of the iceberg). What about the rest of them? Also – and I may be wrong on this – the technique being “relatively new” (may 2010), it appears that the majority of websites that actually use it are trendier websites, where focus is put more on the browsing experience than on the content itself… In other words, what you’re suggesting as a viable approach may work for some newer websites (Boston Globe included), but not at all on the older ones and arguably, on the ones that matter most, like public services, government and so on.
I’m more than happy to acknowledge that at one point in the future, when RDW becomes a systematic component of most websites, that the reading flow issue might dwindle. But we’re really not there yet.
Jared has a point when he says that the horizontal scrollbar issue is in fact a AAA Success Criterion (1.4.8). Indeed, in most context where the requirements stop at level AA only, the horizontal scrollbar issue is simply out of scope, whether we like it or not.
I also agree that it’s a little late once the site is built to go and fix the CSS structure – it’s just one of those things that require way too much effort to justify the costs. But that doesn’t mean we can’t mention it. While it’s ok to acknowledge how much effort that might require from the developer’s part, on the other hand, I am not willing to leave a whole community hang because those same devs were clueless about testing for such things when they created their prototypes…
As we finally start to think a little les about the blind community and a little more about the other user groups accessibility is supposed to cater for, I’m a little uncomfortable with going for the easy way out.
But I have to recognize that when you compare SC 1.4.4 and SC 1.4.8, it would make sense to interpret this as browser zoom is acceptable at level AA and text resize is the golden standard at level AAA. Which goes to show how much the low vision community were just swept under the rug with WCAG 2.0. Nothing on level A? Really?
Hi Denis,
Thanks for commenting, I’ve a few replies:
That should be exactly the problem it solves, as it provides a mechanism to change the number of columns depending on the available width.
I’d love to see an example, how much did you need to zoom in for that? Was text size also increased as well as zoom?
I asked Paul Boag about that (as he is a fairly big ‘node’ in the web dev community), he replied:
My point would be to publicise techniques for what people are working on, not just what sites happen to be sitting there now.
You mentioned Government, have you checked out the biggest UK Government site? You can pump that up to 500% with zoom…
I’m really not trying to give an easy way out, I was one of the people who commented on WCAG 2 to get relative units back in!
I would like to ‘toughen’ the examples behind 1.4.4 to imply that you should be able to zoom in 200% without scrolling, or have to allow for text-sizing to 200%.
But easy is not a bad thing when the result is better. For my money, RWD and zoom provide better results, and I base that on usability testing with low vision users.
That doesn’t mean there aren’t exceptions, and frankly the keyboard accessibility of some RWD navigation is shocking, but I’ve just been working with a set of development teams (over 100 devs), and moving to RWD makes their site 10 times better for low vision users (again, based on usability-testing results).
They had already been testing various devices and different resolutions, so all the layout testing had been done.
The lowest res people tend to test is 320px wide, so a VI user with a 1024 screen should be able to get to almost 300% with desktop zoom showing a one-column layout and no cut-off.
That is so much better than today.
Solid arguments, I’ll give you that. 🙂
I went out looking for some of the “best” RWD sites form various topXX lists and very quickly, stumbled on this one: http://www.unitedpixelworkers.com/.
It’s a perfect example of what I meant – as soon as you start increasing text size in FF, it starts breaking because of the containers in which content is displayed. But if you only zoom, stuff is displayed perfectly.
I agree that a lot of RWD, by default, handle this very well, but not all of them. Of course, this is not surprising, no one expects anything to be perfect. I’m just saying that we can’t be 100% positive about the improvements gained by RWD when it comes to helping low vision users get a better experience.
And I’m sure Paul would be right on this one… I can’t imagine anyone starting a new site today that wouldn’t want it to be responsive and mobile friendly.
Do you know that joke about the man who goes in to the Doctor and says “It hurts when I move my arm like this”? The Doctor says “then don’t move your arm like that!”.
, so only zoom! 😉
I’m very interested in examples of RWD sites that don’t work well when zoomed, either as buggy examples or those that show some fundamental issue. So far blurry images is the only fundamental issue, but I think that is out-weighted by being able to manipulate the columns and keeping it readable.
“I’m very interested in examples of RWD sites that don’t work well when zoomed, either as buggy examples or those that show some fundamental issue.”
It might have more to do with whether browsers go down to the “mobile” stylesheet with zoom. Opera may have been the first, and I don’t know if they all do that now. It’s generally quite nice if they do, except sometimes large “hit areas” for touch get annoying.
Hi Stomme,
If a site is responsive, and the browsers uses zoom, they should all go down to the ‘mobile’ view. (Except in Safari, which has a bug.)
Zoom essentially makes all the pixels bigger, so 300% of a 1024 screen means the browser would report 341px for media query usage. (It will actually display text and images at greater clarity than that implies, but we are talking CSS pixels for layout not device pixels which actually render the content.)
Therefore a responsive site would go to ‘mobile view’. This site isn’t responsive (still using a design from 2006!), but try bostonglobe.com, nomensa.com, Gov.uk, or Microsoft.com in Chrome/IE/FF/Opera.
Once upon a time, we were struggling with text sizing issues on a fixed width design. The designer’s solution was to decrease the initial font size: a menu label wouldn’t fit using IE’s “Largest” “Text Size” with a 12pt font, but by golly, it worked fine at 6pt! Of course, then almost nobody could read it, but the box could be checked.
In addition to technology neutrality, WCAG2 is characterized by its effort to make things measurable. If there was something you could measure, that’s what was looked at for criteria. But just because there is a measurement, it doesn’t necessarily mean that it’s measuring the right thing.
Magnifying a ridiculously tiny font 200% may still not be enough to provide any meaningful usability for low-vision users. Are zoom percentages really the right measurement, or should we be looking for other metrics?
Hi Sarah,
I think there are practical limits, and as you said, no one could read 6pt font so that was an own goal on their part. I haven’t come across that sort of thing for a long time.
The best cross-device measure of text sizing would have to be (CSS) pixels, as that is a measure of angle. Check out my previous article on that topic.
Any ‘absolute’ unit (e.g. cm) would not work due to varying viewing distances, and any relative measure would be relative to CSS pixels. But I”m not sure how helpful it would be to specify minimum pixel sizes? You would need to say that text should be able to reach 24px (for example) without loosing content/functionality.
Most responsive sites do much better than that (on the desktop at least), so I”m not sure about the value?