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.
From a user perspective, there are some big pros in favour of text contrast and size style switchers:
However, there are also quite a few drawbacks of using 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?
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.
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.
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).
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.