5 reasons why WCAG AA compliance does not mean your website is accessible

There's a common misconception, that if you meet the Web Content Accessibility Guidelines (WCAG) 2.2, to level AA, then your website is accessible.

WCAG 2.2 level AA is often considered the holy grail and the target to aim for. When, in reality, it should just be a baseline or starting point. Because, what many people don't realise, is that you can have a "fully-compliant" website that is inaccessible to most people.

This probably sounds confusing, right? But, it's because the scope of WCAG is to make sure that people with impairments are not disadvantaged, not to ensure that the user experience is actually a good one. To pass WCAG 2.2 AA, the user experience is allowed to be absolutely terrible, as long as it's equally terrible for everybody!

In this post, I'll cover 5 examples which highlight why WCAG, as great as it is, is not enough on its own. It's not a giant rubber stamp that automatically means your product or service is actually accessible.

1. Use of colour only applies if colour is actually used

WCAG Success Criterion 1.4.1 Use of Color, is to make sure that people who have a colour vision deficiency, or colour blindness, are not disadvantaged when you use colour in your design.

For example, if you use red to indicate something is bad, then a secondary visual indicator must also be present. To pass, you'd need to add something like additional text, icons, shapes or patterns, to make sure that even if you can't see the colour, you can still understand the information.

However, there is a note in 1.4.1, which states:

This criterion does not apply to situations where color has not been used to convey information, indicate an action, prompt a response or distinguish a visual element. For instance, a hyperlink which has been styled to appear no different than neighboring static text would not fail this success criterion, as there would be no color differentiation between the actionable hyperlink text and the adjacent static text. Such lack of styling differentiation could result in poor usability for anyone looking at the interface, regardless of disability.

So, if colour has not been used, and a link literally looks identical to the paragraph text that surrounds it, then it would still pass this success criterion, even though nobody would be able to tell what is a link, and what is not.

2. Font-sizes can be so small nobody is able to read anything

There is no criteria for minimum font-size in WCAG. Font-size does have to be considered in places, but only really to check other things.

For example, under 1.4.3 Contrast (Minimum), text which is small needs to have a contrast ratio of at least 4.5:1. And, under 1.4.4 Resize text, text needs to be able to scale up to 200% without a loss of content or functionality.

This is sensible, because even in the most extreme circumstances, it's unlikely anybody will launch a website where the font is so small even the designer can't read it!

However, in absence of an explicitly defined minimum requirement, you can "technically" make your font-size 1 pixel high, and as long as it has a contrast ratio of 4.5:1, and you can double it to 2 pixels in size without a loss of content or functionality, it would pass both of these criteria.

So, again, it's a terrible experience, but it's an equally terrible experience for everybody who can see. Nobody has been disadvantaged because their sight is impaired, because nobody can read any of the text anyway.

3. Loading speeds can be so slow you can't actually navigate the website

WCAG does have 2.2.1 Timing Adjustable which focuses on timings. But, it focuses on things which are deliberately timed in the user interface. For example, keyboard shortcuts, session timeouts, or a toast notification which disappears after 5 seconds.

Timing Adjustable is to help people with impairments who might take a bit longer to read, process information, orientate themselves or physically move to interact with components. For example, people with Dyslexia, visual processing disorders (VPD), dexterity impairments, visual impairments or cognitive impairments.

However, what Timing Adjustable does not account for, is things like network latency, database inefficiencies, bloated scripts, server speeds or poorly written data queries.

So, if each page takes 30 seconds to load before it becomes usable, we'd all probably argue the website is totally unusable. But, it would not fail WCAG AA, because if it takes 30 seconds to load a page, regardless of your impairments, the experience is equally terrible for everybody.

4. Language can be so complex you can't understand it

If we look at section 3.1 Readable of WCAG, it covers 6 different success criteria.

• 3.1.1 Language of Page
• 3.1.2 Language of Parts
• 3.1.3 Unusual Words
• 3.1.4 Abbreviations
• 3.1.5 Reading Level
• 3.1.6 Pronunciation

Language of Page, and Language of Parts are level AA. They state that languages used on the page and the elements, needs to be set correctly in the code. This allows assistive technologies to use the correct language packages for pronunciation and dictation.

However, the rest of the criteria, the ones which state that the language has to actually be readable, are all level AAA. And, because level AA is the only level ever mandated in legislation, and the level that is expected, everybody just inevitably ignores everything else.

Under level AA, you can subjectively fail some on content. For example, page titles, links, headings and labels need to "describe topic or purpose" in order to pass 2.4.2 Page Titled, 2.4.4 Link Purpose (In Context) and 2.4.6 Headings and Labels.

The reason I use the term "subjectively fail", is because the person doing the audit is not necessarily a user of that particular product. Although a heading might not describe topic or purpose to the auditor, it may still be perfectly clear within the industry’s established lexicon.

Basically, your content can be super complex, verbose, and so full of acronyms or abbreviations that most people can't actually understand it. But, as long as the language is programmatically set correctly, and things do technically describe the topic or purpose, even if difficult to read, then it would not fail WCAG level AA.

5. Poor quality audio content

WCAG has a several criteria which apply to audio content. It can be a bit confusing to work out which one applies in different scenarios. But, they basically aim to make sure that if somebody cannot hear the audio, there is an alternative way to consume the content.

What WCAG does not mention is audio quality. For example, if you put a recording of a speech online, but it has heavy static, distortion and random bouts of interference which make it unintelligible to everybody, it would not fail WCAG AA long as an alternative was available, such as a transcript.

If nobody can understand the audio, and everybody has to read the transcript, we'd probably argue the audio is inaccessible. But, again, nobody is disadvantaged because of an impairment, it's just a terrible experience for everybody.

Final thoughts

To clarify, this is not a dig at WCAG. It would arguably be a waste of time, and probably an impossible task, to write guidance for every theoretical edge-case. But, having seen some really poor design choices, and some really weird bugs in production, there are definitely some of these scenarios that do play out!

To be clear, the intent of WCAG is not to be measure of UX or a benchmark of a websites performance. Its intent is to make sure that people with impairments, and people without, have equal experiences when using websites, mobile applications and digital services. Even if that experience is a terrible one!

It's common to describe a product as being "fully accessible" because it is WCAG 2.2 AA compliant. But, instead, I challenge you to start thinking about it as a product that is unlikely to disadvantage people with impairments, because it has a measurable base-line level of accessibility.

I know it won't quite roll off the tongue as easily. I know we probably need a snappier way of saying this, but I definitely back the sentiment! I'd be interested to hear your thoughts or suggestions if you have any!

Thanks for making it to the end!
Craig

Post details