Articles

Interpreting WCAG 2.0
The style switcher loophole

09.01.2012

Opinion has long been divided on the use of style switchers for improved text contrast and size. While there are pros and cons, the use of style switchers to provide conforming alternate versions in order to meet WCAG success criteria can cause serious accessibility problems, especially for users with low vision.

Author: Detlev Fischer

Style switchers are controls on the page that allow users to load a page version with contrast settings or text sizes that are better adapted to individual needs than the default settings of the page.

Style switchers may offer stronger or inverted contrast, incremental increases of text size, or even a reflow of content in fewer columns that facilitate a large text zoom factor without overlaps or loss of content.

Pros and cons of style switchers for text contrast and size

From a user perspective, there are some big pros in favour of text contrast and size style switchers:

• many non-expert or older users do not know their browser's menus, settings and short keys and will often never discover customisation even if they may have a sore need for larger text or text with better contrast. Style switchers, especially when well placed and clearly labelled, can aid the discovery of customisation options that would otherwise not be detected and used.
• Style switchers, when recognised and understood, can also make it more straightforward to select custom settings, especially for the many older users who just want slightly larger text. One or a few clicks on the same control will suffice, there is no need to resort to the browser menus of option dialogues and search for the required settings.
• Some conventions have built (the row of 'A's with incremental text size, the contrast icon known from display contrast settings). While these controls are far from uniform and may well be misunderstood, many users have begun to recognise and use them.

However, there are also quite a few drawbacks of using style switchers:

• Style switchers introduce unnecessary noise and (if they are keyboard accessible, as they should be) add extra tab positions at the beginning of the page that can be a distraction to all users who don't need them.
• Style switchers duplicate functionality provided elsewhere, thereby potentially masking more powerful customisation options. For example, if a style switcher allows me to crank up text size to just 120% I may never find out that more powerful browser settings exist. Users may build the wrong assumption that on all pages that don't have style switchers, text size and contrast simply cannot be changed.
• While some conventions exist, there are many different ways of implementing style switchers on the pages out there, forcing users to work out in each case by trial and error how exactly the controls are operated and what changes they cause.
• Often, style switcher controls are poorly labelled to save space and reduce the visual footprint, which is in conflict with the intention to make these functions easily discoverable for those who need them. Some style switchers thereby become a bit of an alibi, not more than a poorly implemented nod to accessibility.

Understanding the function of style switchers

Often, a switch is nothing but a small symbol. It may be supplemented by a title attribute visible on mouse hover and programmatically determinable by assistive technology, but its function is not immediately obvious to sighted users who do not move the pointer over the switch. Whether a switch is actually discovered by the user, especially on busy pages, is more a matter of luck. The test in F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information begs the question whether using a title attribute or a custom pop-up on a symbol that is only displayed when activating the link is sufficient.

The function triggered by activating a style switcher symbol is often far from predictable. Should activating a custom contrast symbol (a circle vertically split into a black and a white half known from display contrast settings) immediately load a style sheet with stronger contrast? Or open a dialogue or a drop-down menu? Or go to an accessibility settings page?

Style switchers as loopholes

So while we can conclude that style switchers have long been a mixed blessing, a new situation has been created with the introduction of WCAG 2.0. WCAG now allows pages that fail to meet WCAG success criteria to achieve conformance when providing to a conforming alternate version via an accessibility supported mechanism (often, this is a switch on the page). To be sure, the definition of "conforming alternate version" requires that conforming pages linking to a non-conforming page must also provide a mechanism to reach the conforming version, or that conditional redirects prevent the loading of non-conforming pages. However, in a situation where most page views are called up from search engine hits and where conditional redirects may not work reliably in all settings, these requirements do not really bite.

No top position requirement for switches loading an alternative conforming version

WCAG requires that the switch (the accessibility-supported mechanism) must meet all WCAG success criteria on the selected level of conformance. However, there is so far no WCAG requirement to position the switch at the top of the page.

This may appear a mere lapse. A comment submitted to WCAG Working group about technique G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast pointed out the loophole, proposing that at least the style switcher position at the top of the page should be mandatory and included in the test of the respective technique. But the WCAG Working Group thought otherwise:

"This technique does not require that the style switcher be at the top of the page. This is just good practice and therefore we included it in the examples to encourage it. It is therefore not in the technique nor in the test criteria. However, we are adding a note about this in the description."
Reply of WCAG Working Group, 23. 03. 2011

One could argue that the WCAG Working Group deemed the meaning of "top position" too imprecise to be testable given the wide variety of viewports and possible page renderings. In another technique however, G198: Providing a way for the user to turn the time limit off, WCAG apparently had no problems with mandating a top position of a switch.

No default contrast requirement for pages with a conforming alternate version

Regarding success criteria 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced), the option to meet criteria by providing an conforming alternate version shows a very serious shortcoming from the point of view of users with low vision. The Sufficient Techniques for 1.4.3 and 1.4.6 have no requirement regarding the default contrast of pages. This means that while it is clearly bad practice, it is fully conforming to WCAG 2.0 to offer users a page with laughably low default text contrast provided that a style switcher exists somewhere, anywhere on the page that will load a conforming alternate version (an different page or another style sheet providing better contrast).

Conclusions

The answer of the WCAG Working Group is unsatisfactory and invites suspicion that the loophole is intentional, allowing site owners to circumvent a requirement crucial especially for users with low vision, but important also for the much larger group of elderly users.

In our opinion, a minimum level of contrast should be required for all content regardless of the existence of alternate versions. The required contrast might be well below 4.5:1 for sites that do use style switchers, but it should prevent a situation where users have to struggle with light grey on white while the pages in question can still claim that they meet WCAG even on Level AAA.

If style switchers are used to meet WCAG Success Criteria (not just for optional views on pages that already conform to WCAG on the chosen level), there should also be a clear requirement (not just a recommendation) that they are placed at the top of the page, both in terms of source code order and in terms of the visible display.