20.08.2011
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 widgetsbut 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.
This is why the new BITV-Test checks both for page zooming in checkpoint 1.4.4b and text-only resizing in checkpoint 1.4.4a.
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.
© 2023 DIAS GmbH | Imprint | Accessibility | Privacy Policy
