WCAG 2.1 Minimum Contrast

Introduction

At work, a project website delivered by a contractor claimed to be WCAG 2.1 AA compliant and had a certificate to prove it. This was despite the fact that the site was clearly failing on the minimum contrast requirements and any automated accessibility checker would tell you this. I dismissed the certificate as a sham. A more eagle eyed colleague, a lawyer no less, noted that within the certificate document was the acknowledgement of the minimum contrast issue, alongside a note that this was fixed through an accessibility overlay where the user can switch to a high contrast view. Not possible, I screamed into an email. Of course, the lawyer was right.

For now we will ignore the idiocy of installing an accessibility toolbar, when it would have been simpler to change the colour of the text in question from dark grey to black!🤦

Contrast

The guideliness have this to say for minimum contrast:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

  • Large Text Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

  • Incidental Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

  • Logotypes Text that is part of a logo or brand name has no contrast requirement.

They also have extra help on the guidelines, including Understanding Contrast and How to Meet Contrast (Minimum).

Help on the guidelines

Digging into the this extra information, you come accross technique G174: Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast. This technique explains that you can provide an alternate version to meet conformance requirements for these three criteria:

  • Success Criterion 1.4.3: Contrast (Minimum)
  • Success Criterion 1.4.6: Contrast (Enhanced)
  • Success Criterion 1.4.11: Non-text Contrast

And goes on to state that

For this technique to be used successfully, three things must be true:

  • The link or control on the original page must itself meet the contrast requirement of the desired SC. (If the user cannot see the control they may not be able to use it to go to the new page.)
  • The new page must contain all the same information and functionality as the original page.
  • The new page must conform to all of the SC for the desired level of conformance. (i.e., the new page cannot just have the desired level of contrast but otherwise not conform).

I can understand the reasoning for this in well defined edge cases. These include historical content or content that cannot be legally changed. However this technique should not be applicable outside of these edge cases. ie the way to pass the contrast criteria is to alter the contrast on the page itself. Only in a few edge cases should an alternate version be sufficient.

Digging deeper

Anyway, the existence of such a technique really knocked my confidence in the WCAG, and especially my understanding of them. Why would the edge cases not be more clearly delimited? There must be a catch somewhere I thought. There isn't. This technique really exists and gives a carte blanche to claim a page with white text on white background meets the WCAG 2.1 AA because it has a link to an alternate accessible version. Why should a disabled user have to search the page for an alternate version, when adjusting the contrast is such an easy thing to do for the designer. Why push the burden on someone probably already struggling to use the page.

The conformant alternate version link above does note the following:

Authors relying on conforming alternate versions must make end users aware that a conforming alternate version is available. This may be accomplished by providing a link to a more accessible version, identified clearly by link text. Alternatively a link to instructions may be provided which documents how to access a more accessible version as well as the specific ways the alternate version is more accessible (e.g. a "high contrast version").

In the case of the project site, the need to be "identified clearly by link text" actually fails for a nunmber of reasons, in my opinion:

  • Accessibility bar required javascript in order to work. It is not clear to me if requiring javascript is OK for meeting the WCAG.
  • The bar, whilst generally apparent, is not as noticable as it could be
  • The bar gives no obvious hint that you can adjust the page contrast by using it
  • The bar is hard to use with a keyboard.
  • The bar functions through buttons and images, not links. But the technique states "link text" so for me this is a fail.
  • ...and in a screen reader all you hear is "button, button, button". OK, a screen reader user won't usually be bothered by low contrast, but still.

And also this:

A concern when permitting Web pages that do not satisfy the Success Criteria is that people with disabilities will encounter these non-conforming pages, not be able to access their content, and not be able to find the “conforming alternate version." A key part of the Alternate Versions provision, therefore, is the ability to find the conforming page (the alternate version) from the non-conforming page when it is encountered. The conformance requirement that permits alternate pages, therefore, also requires a way for users to find the accessible version among the alternate versions.

Unusable accessibility

Of course usability and accessibility, whilst heavily intertwined, are not the same. It is possible to meet all accessibility criteria, even after a manual check and be completely unususable. OK, you would probably have to try quite hard to achieve this, harder than making the page accessible in the first case, but here goes:

This page meets all WCAG contrast requirements

This one on the other hand does not, because there is no link text

Tagged: