What do you need to do to ensure that users can resize the text on your web page? A quick look at WCAG's "How to meet 1.4.4 (Resize Text)" suggests that relying on browsers' page zoom is sufficient. So far, failure F69 has given us reason also to require text-only resizing to work. Now WCAG WG has announced an overhaul of F69.
Author: Detlev Fischer
The original article discussed the requirements for web content text resizing in WCAG 2.0, as expressed in the success criterion 1.4.4 Resize text. The article was originally published in 2011 and last updated in January 2012. At the time, the point of contention was whether the success criterion 1.4.4 could or should be interpreted as requiring web authors to support text-only resizing of web content (beyond supporting page zoom).
In the meantime, the growth of web usage on mobile devices and the spread of the responsive web design paradigm have changed the approach to text resizing somewhat.
A well-designed responsive site will react to page zoom both by increasigng the text size and offering a simpler layout. On narrower screens, the multi-column layout shown on the desktop browser will become a single column layout - read Alastair Campbell's post Browser zoom great for accessibility.
On the same responsive site (look at incobs.de for an example), text-only resizing may not have the desired effect or even lead to a behaviour that users would expect from page zoom - when layout elements are all defined in
em, the entire content will grow as users trigger text-only zoom.
On non-responsive sites, supporting text-only magnification will still be beneficial for many users.
The mobile browsing experience is different. Some mobile browsers (Safari on iOS, Firefox on Android) do not offer text-only magnification that will lead to a text reflow, while others (Google Chrome) do. Most mobile browsers have in common that a pinch gesture can be used to zoom in and out of a page.
Many modern mobile browsers (Safari on iOS, IE11 on Windows 8.1, Blackberry Browser) now also include a reader mode that will present the page content in a simplified one-column view that can often be customised to suite users' reading preferences. To some extent this negates the need for text-only zoom (on mobile). And there are mobile apps like Pocket that will provide a customisable reading experience for web pages saved during browsing.
Regarding the WCAG Working Group position, the article is still up-to-date today: the response from the WCAG Working Group regarding the text resize issue has not changed since the 2012 update was published, and failure F69 has not yet been updated.
(end of 2014 update)
While WCAG 2.0 state that text resizing is mainly a responsibility of the user agent, the page has to be built in a way that it does not prevent graceful text-only resizing (compare, for example, Check your design with text size increased to 200 percent by Roger Johannsson of 456 Berea St).
One check has to be the level of support for page zoom by user agents. Understanding Success Criterion 1.4.4 explicitly refers to user agents that do not support page zoom, such as IE6 and Firefox before version 3. The share of people still using IE6 differs strongly by country; while Internet Explorer 6 Countdown estimates a world-wide share of 10.7% (June 2011) the share in Germany is much lower with 1.8% (UK 2.6%, US 2.0%). So as the use of IE6, older versions of Firefox and other browsers not supporting page zoom may have fallen below 5%, one could be tempted to argue that the rationale for supporting text-only resizing is evaporating.
We leave aside another option for meeting SC 1.4.4, sufficient technique G178 which covers controls for text resizing. @webaxe has listed reasons to 'say no to text resize widgets'. Well, there are also arguments in favour of such widgets—but text resizing via the browser controls should work, regardless of whether such a widget is offered or not.
The success criterium 1.4.4, being technology-neutral, makes no reference to specific techniques to meet the requirement:
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)
The decisive link between success criteria and the multitude of implementation techniques is the respective section of the "How to meet" document. The section for SC 1.4.4 lists four options for achieving conformance and is equally provided in the Understanding SC 1.4.4 document.
These documents are not normative, meaning that they reflect the consensus of the accessibility community and other stakeholders what sets of techniques are considered sufficient to meet the respective success criterion. In the case of SC 1.4.4, option 1, there is just the technique G142: Using a technology that has commonly-available user agents that support zoom
So what demands does technique G142 impose on web developers and designers? In most cases, none at all. Even static designs all defined with pixel dimensions will scale fine when applying page zoom in all but dated browsers.
Should we let designers off the hook so easily? Actually, I think that failure F69 provides some evidence that pages must also support text-only resizing to conform to SC 1.4.4 because its description refers to "a problem that occurs when changing the size of text causes text to be clipped, truncated, or obscured, so that it is no longer available to the user". In our experience, this is a very common problem when applying text-only resizing, but rarely occurs in page zoom.
Some experts however seem convinced that F69 refers to page zoom. Roger Hudson (@rogerhudson), twittered, for example:
I agree with @stevefaulkner. I think to suggest F69 requires text resize is incorrect. F69 is about loosing content with zoom
We concede that F69 does not explicitly refer to text-only resizing. Neither does it explicitly mention page zoom. The test included just states: "Increase the text size of the content by 200%", which may happen both ways.
This is where the examples of F69 come in. Two screenshots are provided to demonstrate the text overflow or clipping failure condition:
Screenshot of F69, example 1 (text overlap)
Screenshot of F69, example 2 (text clipping)
I have tested the HTML code provided with the examples in a range of browsers: on OSX (Firefox 3.6 and Safari 5) and on Windows XP (Firefox 5, Internet Explorer 7 and 8). In none of the browsers there is any problem with scaling the examples using page zoom. When selecting text-only zoom, however, overlapping and clipping occur. (One exception is the first example in IE8 on Windows XP where the box grows vertically, while in the second example, the text is clipped.) I take this as (perhaps inconclusive) evidence that F69 really deals with text-only scaling.
There are indeed very good reasons to support text-only resizing even if the user agent supports page zoom. When reading online, container widths stay the same while the text within containers is comfortably enlarged without necessitating horizontal scroll. Users retain an overview of the full page without having to veer right and left to see areas outside the viewport.
We think that presenting page zoom as one complete option to satisfy Success Criterion 1.4.4 is a serious disservice to the large number of visually impaired or aging users out there. Our recommendation would be to change the "How to meet 1.4.4" document so that G142: Using a technology that has commonly-available user agents that support zoom will satisfy the Success Criterion only in conjunction with techniques affording text-only resizing. Currently, the need for a support of text-only resizing is implicitly given in F69, but it must be inferred from reading and interpreting the failure; it is not evident on the level of options for sufficient techniques.
Supporting the resizing of text to 200% will be very hard to achieve in practice. However, supporting a more modest level of 150% is quite doable, as demonstrated by several of the multi-column online news sites we have investigated.
In a related quick test, we have checked how well text-only resizing is supported by a grab sample of popular news media: The case for text-only resizing: a look at twenty online news sites.
In the meantime, our comment about inconsistencies in Technique F69 regarding what we percieved as implicit requirement for the support of text-only resizing in the examples provided, has led to a lengthy debate within the WCAG Working Group. A special survey, "What shall we do with F69?", was published and closed on 1 December 2011. Active members were divided as to whether and how the technique should be retained.
Five WG members voted for the option not to change F69 at all, but to add the note that is now included in the description of the technique:
Note: The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure.
F69, Update January 3, 2012
Five WG members voted for adding examples that fail page zoom and also, add the note that F69 will be revised.
One WG member voted for the deletion of the failure.
One WG member suggested to amend the test in F69 to check whether text can be resized in several ways:
The test would then check if scaling text to 200% is successful (no overlaps or truncation) in any of the three techniques. If so, the Success Criterion would be met.
To sum up, the current position of the Working Group is divided, but has been provisionally clarified in the note. Until further notice, if any technique can be used to scale text successfully to 200%, the Success Criterion 1.4.4 is met. I will report on future F69 updates.
Regarding our test procedure, BITV-Test, the WCAG Working Group decision has led to a public debate whether our checkpoint for testing text-only resizing should be scrapped and just one checkpoint for SC 1.4.4 be created covering all common techniques for text resizing. This (German) debate is available on the WAI-DE Mailing list. As yet, no decision has been made when, if and how to change BITV-Test.
In your article you rightly refer to how the Understanding SC 1.4.4 document raises the issue of browsers that don't provide page zoom. That page says "The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6 or Firefox."
It also says "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent. If the user agent doesn't provide zoom functionality but does let the user change the text size, the author is responsible for ensuring that the content remains usable when the text is resized."
Forgive me for quoting those passages at length, but I do so because I think they help explain how, at least as I understand it, the application of SC 1.4.4 is related to the browsers that a site means to support. The SC seems rather reliant on this. If IE6 or pre-zoom browsers are considered part of the site's browser support baseline, then graceful text-only resizing would be a requirement.
If support for those browsers is not a concern, then enabling text-only resizing is not a requirement as there is, presumably, page zoom in the other browsers that the site is supporting, and as long as that works well, this satisfies SC 1.4.4.
F69 only identifies a failure where text-only resizing breaks the page. This is not the same as requiring that text-only resizing be enabled for a browser, unless support for that browser is intended.
So, as I read it, SC 1.4.4 says that text must be able to be resized to 200% without loss of content or functionality, whether this is done through text-only resizing or page zoom, or both. But, in accordance with F69, if the browser and page together allow for text-only resizing, then the page had better not break via text-only resizing.
As such, in a corporate environment where everyone is forced to use IE8, an intranet could use pixels for all fonts and satisfy SC 1.4.4 since page zoom is available, assuming the pages resize well this way. SC 1.4.4 would not require that text-only resizing be enabled through the use of em or % units, and, in order to allow for such scenarios and flexibility in design, I don't think it should. The pages remain accessible with regard to text resizing by virtue of IE8's page zoom functionality.
For the record, though, I do consider enabling both text-only resizing and page zoom to be best practice, since it affords greater user choice.
@Jason: OK, I see what you mean. I guess my main point is that SC 1.4.4 on its own - i.e., just the normative part - does not suggest (to me) that page zoom alone is fine. It is agnostic on techniques. Only the (not normative) "How to meet" document does, in option 1.
So it is up to the community to interpret SC 1.4.4. If (not normative) F69 embodies the community consensus on what constitutes a failure, then it should correspond to the (not normative) options for meeting SC 1.4.4. And my point is that they are in conflict.
You agree that "when checking for compliance with 1.4.4, it is necessary to test that text-only resizing, if enabled for the browser, does not cause loss of content/functionality". If that is indeed necessary, should text-only resizing not also be required as necessary part in any sufficient option to meet SC 1.4.4?
Sorry. That's not what I meant to suggest.
SC 1.4.4, along with its related sufficient techniques and failures, suggests to me that text-only resizing is not required, and that page zoom alone is fine. At the same time, however, the same page must not break via text-only resize, even if page zoom is available and works fine.
So, for example, in IE7 or above, a page that uses only pixels will not scale via text-only resize, but might scale just fine using page zoom. This would pass 1.4.4.
But a page that uses em or % and does not scale fine in IE via text-only resize would fail 1.4.4, even if page zoom worked well. For this reason, when checking for compliance with 1.4.4, it is necessary to test that text-only resizing, if enabled for the browser, does not cause loss of content/functionality.
Sites enabling text-only resizing in IE by using em or % would be more likely to fail SC 1.4.4 than static sites with fonts in px only because it takes extra attention to detail on the part of the designer/developer to ensure that content/functionaly doesn't break at 200%, whereas page zoom will more likely work fine.
I agree that enabling the albeit imperfect text-resizing in IE is better than not enabling it. But, unless one *needs* to support IE6, page zoom is otherwise available and serves to meet SC 1.4.4.
@Jason: Your example seems to imply that sites enabling text-only resizing in IE by using em or % would be more likely to fail SC 1.4.4 than static sites with fonts in px that will not respond at all to text-only resizing in IE.
I would have thought that imperfect (e.g., less than 200%) text resizing is still preferable to having no text-resizing at all (in IE). Interpreted this way, F69 seems to produce counter-intuitive results.
In my earlier comment I wrote "If F69 is about text resizing, as opposed to page zoom, and the scenario it describes constitutes a failure of Success Criterion 1.4.4, isn't this saying that a page must not cause loss of content or functionality when only text is resized to 200%? In other words, isn't it saying that text-only resizing is required?"
I'd like to amend this, since they are not exactly the same thing. That is, not causing loss of content or functionality when only text is resized to 200% is not the same as fully requiring that pages provide for text-only resizing in all user agents. In IE, text sized in pixels won't resize, but the page as a whole, including text, can zoom to 200%. In this case, if all the content/functionality are still there, I'd consider SC 1.4.4 met. On the other hand, if the text were sized in ems or percentages, and the content/functionality broke at IE's "Largest" text size setting, that would be a failure.
@Jason: thanks for pointing out the ambiguity regarding the non-normative nature of failures. Interestingly, in the tests of failures, the common disclaimer found under the tests of techniques is missing ("If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.")
@Roger: I think all experts agree that it is best practice to support text-only resizing - I just think that option 1 in the "How-to-Meet" doc for SC 1.4.4 really invites designers and developers to believe that no extra care is necessary since in most cases, their designs will zoom-magnify OK. I am actually not quite sure what the difference between your two tweets is, and in what sense the second corrects the first...
I find the relationship between sufficient/advisory techniques and failures somewhat ambiguous, especially as provided in the Introduction to Techniques for WCAG 2.0.
In the first paragraph of that document, techniques and failures are fairly clearly distinguished from one another. Also, in the subsection on "Sufficient and Advisory Techniques" on that same page, there is no mention of failures. Only the techniques are clearly identified as advisory and not normative.
The same document says that the failures "describe common mistakes that are considered failures of WCAG 2.0 Success Criteria".
If F69 is about text resizing, as opposed to page zoom, and the scenario it describes constitutes a failure of Success Criterion 1.4.4, isn't this saying that a page must not cause loss of content or functionality when only text is resized to 200%? In other words, isn't it saying that text-only resizing is required?
Thanks for the thoughtful article. But, kindly acknowledge the following later correction to my tweet you quote:
"Sorry @wcagtest and @stevefaulkner I meant to say F69 is about loosing content when resizing text. Don't think it requires use of text resize"
I made this comment because I believe F69 is mainly there to address overflow problems that can happen when text is resized. But I don't believe it says you must use relative text sizing as was the case with WCAG 1.0. With this comment I am not suggesting you shouldn't enable text resizing - of course wherever possible this is most likely to be the best approach. As you mention, the techniques are only advisory not normative.