This post was motivated by a discussion that took place while the EasyChecks document was being developed over at the Education and Outreach Working Group. During that time, colleagues and myself were also reviewing our manual testing methodology and found we were not in agreement as to how to interpret some of the WCAG 2.0 Success Criteria, including SC 1.4.4 – Resize Text. Right. Like disagreeing on WCAG 2.0 interpretations never happens in our field.
As it turns out, I have been involved in a lot of discussions recently over the interpretation of various Success Criteria when it comes to testing for WCAG 2.0 conformance, and SC 1.4.4 was one of them. Part of those discussions revolved around whether or not testing for browser zoom (increasing the size of the content for the whole page proportionally) was a sufficient enough technique to meet the WCAG 2.0 requirements, or if HTML actually required us to specifically test for text zoom (increasing only the text in the page) instead.
To my surprise, the discussion was much more complicated than I had anticipated and our team couldn’t reach consensus. As a matter of fact, most people were under the impression that browser zoom testing was “good enough” to pass SC 1.4.4. A deeper review of the Success Criterion was required. As a reminder, here’s what the Success Criterion actually says:
SC 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. (Level AA)
Notice that while the Success Criterion explicitly mentions that “text can be resized”, it does not rule out the fact that the word “text” here can have two meanings: the “text” as in the text in the page, and the “text”, as in the content in the page. This may sound like pedantic crap from people who read way to many specifications, but believe me when I say this… when your job is to evaluate the accessibility conformance level of websites, and organizations come to you for expert, professional advices, clients who may or may not be under litigation for WCAG 2.0 or Section508 compliance, these little details become insanely important.
You do not want to call out a violation on something that is simply a best practice or a matter of personal preference (and incidentally, create additional remediation efforts – and costs – for your client, beyond what is truly mandatory or beyond what they are willing to do at this specific point) – something we actually see a lot of. While you may believe in pushing the accessible user experience to its limits, you also have the responsibility to make sure that your interpretations are rock solid and your actions are in line with your clients expectations. That you could defend your interpretations in front of a judge, and have a reasonable chance of winning.
As it currently stands, the WCAG Working Group is unclear in the Understanding SC 1.4.4 document about which approach should be privileged for testing whether or not the Success Criterion is passed. This is due in great length to a specific passage that is provided in the examples section of the Understanding document that reads:
“A user uses a zoom function in his user agent to change the scale of the content. All the content scales uniformly, and the user agent provides scroll bars, if necessary”.
This passage blows the door wide open for a whole new interpretation of what “text” means in SC 1.4.4. Quite frankly, if that example is not an blatant support for browser zoom testing from the WCAG Working Group’s part, then I don’t know what is.
Technology agnosticism, yada yada yada
Now, to be fair, the whole point of WCAG 2.0 is being technology agnostic, so it is the WCAG’s responsibility not to be HTML centric. I get that. Arguably, in other contexts, maybe the equivalent of testing with browser zoom only could be acceptable, including use cases that impact people with low vision. But when it comes to the web, browser zoom testing to ensure accessibility is totally useless and irrelevant. Worse, it’s actually a recipe for disaster, as I will explain in a minute. In other words, I feel the intrinsic motivation in WCAG 2.0 to reach for a broader perspective and be forwards thinking when it comes to accessible technologies hurts the low vision community on the web… today. One of the user groups – if not THE user group – this Success Criterion actually tries to help.
That being said, let’s keep in mind that the example mentioned above is not part of the accessibility guidelines themselves… it is not part of the Success Criterion. It is part of the Techniques document. And as we know:
- the Understanding documents and the Techniques that ensue are informative (which means that they may or may not be followed to achieve WCAG 2.0 conformance), and
- the Success Criterion – the normative part (the only part that would truly matter in a court of law) – specifically mentions “text resize”, not “browser resize”.
I wish the WCAG Working Group would modify the wording in Understanding 1.4.4 so it becomes clearer that what we truly need to test for is text zoom. Maybe we need a specific HTML Technique that enforces that, instead of relying simply on a General Technique (G142 – Using a technology that has commonly-available user agents that support zoom)?
For one thing, removing the above mentioned example from the Understanding documentation for SC 1.4.4 would help make a much stronger case for text zoom when it comes to testing for HTML accessibility. At the very least, I believe we need to at least put this example in a different context when it comes to HTML. Even EOWG has taken sides for text zoom in the EasyChecks document by saying “
[…] some browsers provide functionality to zoom only the text. If possible, you should check zoom text only“. This is not an over interpretation from the EOWG’s part at all. It’s just common sense, based on arguments such as those coming up in this post.
Needless to say, depending on your bias, you could be led to believe either browser zoom or text zoom (or both) are acceptable in order to pass this Success Criterion. It can also be argued that with browser zoom now available in most, if not all serious web browsers today, the whole issue of content magnification and resizing text increasingly falls under the category of usability and user agent issues for a lot of people. I believe it is a big error in judgement, one that leaves a significant user group out of the digital equality loop – users with low vision. So, without further ado, here are the reasons why I strongly believe we need to make a case for testing for text zoom, not browser zoom, when it comes to testing against Success Criterion 1.4.4.
Drum roll… Browser zoom is pointless for HTML accessibility
There, I said it. Let’s face it, testing for browser zoom is pointless. With browser zoom. pages can never “break”. Since everything always turns out looking proportionally consistent when you magnify your whole page, one could reasonably wonder why we should bother with testing that at all. If browser zoom was an effective way to test for SC 1.4.4, then I would argue we stop testing for SC 1.4.4 altogether when it comes to web content, and we take it out of our WCAG 2.0 testing methodology. While I do not have the authority to make that call on behalf of WCAG 2.0, “we” as a community might decide that we know better. There’s really no point in doing browser zoom testing on any page, because none of the pages will ever fail such a test. With text zoom however, it’s an entirely different matter.
I don’t believe any of the WCAG 2.0 Success Criteria should become obsolete. A part of me is motivated by keeping much of the spirit and relevancy of this Success Criterion alive. I can admit that much. That is my bias. If the testing methodology we use renders the Success Criterion irrelevant, then I question the methodology, not the relevancy of the Success Criterion.
Back in May, during AccessU, I had the pleasure of discussing this issue with Wayne Dick, a leading expert on assistive technology and low vision. Wayne expressed a powerful case for text zoom support when it comes to testing for SC 1.4.4 and resizing text. This is what made me see the light. It went something like this.
Content magnification – A question of Memory, Acuity & Flow
Three principles lead to lean towards text zoom and not browser zoom when we think about low vision users: memory, acuity, and flow. These principles relate to the reading experience in general.
Memory – When using a webpage, a person with moderate low vision (say, 20/70 to 20/200) approaches the problems at different levels. First, low vision users often memorize the organization and layout of frequently used pages, probably more than “normally” sighted people do. They generally proceed by position rather than actual reading, which obviously becomes a big deal to them for orientation. With slightly more text enlargement, users can manage to use print near their acuity limit, along with remembered layout to operate pages as efficiently as possible. Finally, when it becomes necessary for them to read with comprehension, low vision users will need to zoom up to a font size that is usually bigger than the critical print size, to achieve the state where the only mental concentration required is to comprehend the content itself. Something most of us do, simply using the page as it’s presented to us.
Acuity and Flow – For most people with moderate low vision, 200% of say, a 10pt font is between the acuity limit and that critical print size, the point where reading becomes optimal. For people at the upper end of that spectrum, with a vision of 20/140 to 20/200, it may very well be below their acuity limit near point. It is, to them, inadequate to achieve a state of “reading flow”. It can be operationally effective for simple tasks, but cannot be used for any kind of “professional reading”.
Now, some of us might think this a rather small issue, as the low vision user group is a small population and the disability is slight, but neither is the case. According to Wayne, moderate low vision constitutes more than half of all people with visual impairments, including everyone who is blind. Newsprint, for example, is below the acuity limit for everyone in this population without use of assistive technology. Without significant assistive technology, nobody in this group can gain employment that involves reading.
This becomes important when we think about testing for text zoom as opposed to browser zoom, since we, as accessibility professionals, are supposed to be the gatekeepers of digital equality (yeah, I like the sound of that).
Text enlargement and word-wrapping need to work in conjunction
Another fact: it is naive to think that enlargement without word-wrapping is minimally effective, especially on a rather small screen resolution.
A web page is two dimensional: enlargement without word wrapping means that your reading viewport is effectively linear, with every line on the page being noise except for the one in focus. As Wayne puts it, reading long difficult documents in this mode is nothing short of hell. Just think of situations where you have to scroll horizontally for content and how much of a pain in the neck it can be to get back to the following line. Multiply that by your current screen magnifying zoom level (thus, less words visible at once and a much harder process to get back to the next line of text) and picture that on every website, all the time. This is not a problem browser zoom testing can help avoid. It’s actually a problem it exponentially increases, as the real issues (exposed by text zoom testing) remain unnoticed.
So, for any serious reading at all, 200% text enlargement is the bottom level where reading becomes possible – some will argue that it’s still not enough (after all, a 10pt font becomes only 20pt and most users seem to start feeling comfortable around a 28pt font size). Moreover, without text-only enlargement, people quit reading all but text that is vital for their livelihood – and that is a real tragedy. In summary, most low vision users get shut out, 200% text zoom is marginally adequate, and zooming of the entire page can be worse than useless. When we neglect to test for text zoom and only rely on browser zoom, we leave out a critical aspect of what makes content readable on the web for people with low vision.
Another group bites the dust
I have observed a recrudescent concern lately in our community to make accessibility about more than just a matter of improving the experience of screen reader users – which is great. While a lot of this shift has to do with WAI-ARIA and who really benefits from it, on the other hand, we really can’t say that there are a lot of things in WCAG 2.0 that are specifically intended to cater to the needs of low vision users. Success Criterion 1.4.4 is probably the single most important requirement for accessibility to this user group (except maybe for SC 1.4.5 and SC 1.4.9 for images of text). I feel that by considering browser zoom testing as a sufficient method of passing SC 1.4.4, we as a community are pretty much giving up on this user group.
When we don’t make a case of testing specifically for text zoom – the configuration these people ARE USING, we miss those important cases where text starts to overlap or where content becomes lost beyond the fixed-width portions of the page. Browser zoom never reveals such problems, as all it does is create a horizontal scrollbar. But text zoom reveals them. Brutally. Indeed, dealing with text zoom issues is a much bigger problem to solve for developers and most sites might actually fail this because of the way CSS files are organized, but when there is a real barrier to accessibility, I feel my job is not to go easy on developers who should know better. My job is to help foster digital equality for everyone.
Testing for text zoom
Testing for SC 1.4.4 using NoSquint with FireFox is a very simple and effective way to verify if the page has such problems. It takes but a minute to do, results are very clear and the margin for error is next to zero. As SC 1.4.4 is likely the only Success Criterion that really helps low vision users achieve some level of reading comfort on the web, it seems totally irresponsible for me to consider anything but text zoom testing when it comes to how conformance can be measured. So above and beyond what the Success Criterion actually says, my biggest concern is helping low vision users get the best experience they can get on an accessible website. I don’t feel I am doing that by only considering browser zoom testing. Do you?
There. I think I’m now out of ammo. Next?