Home Blog We need to talk about WCAG.

We need to talk about WCAG.

18-05-2021

TL;DR

In this post, I am asking the accessibility community for help. Help for site owners, developers, designers and content managers all over the world. Complying with accessibility guidelines is hard because they are so inscrutable.

One concern is that the specifications and documentation online are inaccessible, unreadable, duplicated, confusing , unnecessarily overcomplicated and cluttered.

Another concern is the addition of new Success Criteria before the existing ones have been properly understood, documented and implemented.

I describe what I encounter “in the field”, as an accessibility expert, auditor, reviewer, developer and researcher. I want to pinpoint the issues and make some recommendations.

The conclusion:
Make the W3C specifications and documentation accessible to web creators, unambiguous and easier to maintain. Provide training and example material using modern web development techniques, keep all this in one place and well maintained. Stop adding new Success Criteria before the most recent ones have been properly documented, explained and better adopted into websites worldwide.

To help the web creating world build an accessible web, the best we can.

First of all

The Web Content Accessibility Guidelines (WCAG) are a valuable and an essential tool for improving and safeguarding web accessibility worldwide. By using the Success Criteria we can check and report issues, and help developers, content managers and designers to improve their work.

Improving the existing guidelines is also necessary. The web changes, and therefore the guidelines should follow.

In this post, I do not dispute the need for WCAG or the need for updates.

The web is broken

The recent WebAIM Million – An annual accessibility analysis of the top 1,000,000 home pages concluded that 97.4% of home pages had detectable WCAG 2 failures! This was down slightly from 98.1% in February 2020.

This is the state of the web at the moment. Therefore, I conclude that the way we communicate and teach WCAG, or even semantic HTML5, to web creators is clearly not sufficient. We cannot continue like this.

This post is written from my point of view, as an accessibility expert. Someone who reviews, audits, researches accessibility and helps web creators with their work.

I’m not a W3C member, I’m not involved in the development of guidelines or politics; I work in the field. Please let me share some of my concerns and ideas.

The information architecture of the WCAG documentation needs improvement

Like most developers and researchers looking for documentation and specifications, I also use a search engine. And then I have a hard time figuring out what the status is of the W3C page I’m looking at and what this status means.

Is it a draft? Is it outdated? Is it for WCAG 2.0? Or for WCAG 2.1? Am I looking at actual, valid and recent documentation or specification?

On the archive page w3.org/TR/, there is an overview of all standards and drafts. Each document has a status:

Candidate Recommendation (CR)s
Group Note (Note)
Proposed Edited Recommendation (PER)
Proposed Recommendation (PR)
Recommendation (REC)
Retired (ret)
Working Draft (WD)

And a version: ‘Latest’, ‘Upcoming’, ‘Editor’s draft’. There are pages with Success Criteria, Understanding and Techniques. All of these documents show up in Google searches.

WAI Guidelines and Techniques turns up as the first result when I search for “techniques WAI”. This is a draft website from 2004. Instead, the recent and valid page WAI tools and techniques should come up first.

Some projects seem to have been abandoned or preserved for internal use, like Start with Accessibility – Education & Outreach.

My point is: the only way to understand this system is to know how all the documentation is set up and what the status means. You cannot expect a developer to know the difference between a CR, PER, REC or WD.

All developers use search engines for answers. It’s hard to make sense of all the different WCAG and W3C documentation out there, if you are not an accessibility expert.

And even then it takes effort to find the right documentation.

The content of the W3C documentation needs reviewing and updating

I’d like to give two real life examples where the online WCAG documentation is not helping developers and needs improvement.

First example: the title attribute

Imagine you are a developer and you want to know how to use the title attribute according to WCAG.

What do you do? You Google it. For example: “title attribute WCAG”.

The first W3C results (for me, in the Netherlands, logged out from Google) are:

H33: Supplementing link text with the title attribute (for WCAG 2.0)
H65: Using the title attribute to identify form controls when the label element cannot be used (for WCAG 2.1)
H65: Using the title attribute to identify form controls when the label element cannot be used (for WCAG 2.0)

And then you:

Choose the first.
Skip the text and go straight to the code example (developers don’t read)
Copy/paste the code example and use it as is.

The result:

<a href="http://example.com/WORLD/africa/kenya.elephants.ap/index.html" title="Read more about failed elephant evacuation"> Evacuation Crumbles Under Jumbo load </a>

Personally I would mark this code as bad practice, accessibility-wise, as not all the information is available to everyone.

Mobile users do not get the “Read more about failed elephant evacuation” info. The Deque study Text Links: Best Practices for Screen Readers, shows that screen readers handle the title attribute differently.

H33 also links to a post from 2004 by Brothercake about tooltips – in both the WCAG 2.0 and 2.1 versions. This information is not helpful for the modern web developer. There are better and more modern ways to add a tooltip.

Yes, it’s a Technique and not a Success Criterion. But tell me, how many people know the difference between normative and non normative? Worldwide, besides accessibility experts? More than 10? If it’s on a W3C page, it must be true and the way to do it.

Second example: False positives

A client emailed me with a complaint: a plugin on their site does not comply with WCAG, describing an error Total Validator (TV) reported in an automated accessibility scan.

It seems that Total Validator marks adding a label below a text input as an error, a violation. Even when there is a proper for/id connection between the label and the input. Where did TV get this idea from?

TV reports the error as:
E874 [WCAG21 3.3.2 (A)] The matching <label> text must appear before/after the control Associate labels properly with their controls. See WCAG 2.1 HTML Technique H44.

Digging into H44, at the very bottom of the page it states:

“Check that there is a label element that identifies the purpose of the control before the input, textarea, or select element .”

So, clearly, this automated checker doesn’t know the difference between a Success Criterion and a Technique either and reports a deviation from a suggestion in a Technique as a violation.

Outdated Techniques are harmful

Developers are copy/paste people. At the very least, the documentation, and especially code examples and links in the most recent and most used Success Criteria, should be modern, sound and valid. One argument against this is that it would take a lot of time to check and update the incredibly numerous Technique and Understanding pages out there. They are very hard to maintain.

Adding new Success Criteria now is counterproductive

Adding new Success Criteria, before the most recent ones have been properly understood and implemented, is counterproductive. Adding new Success Criteria while the old ones are ignored by so many websites seems like a hopeless quest to me.

Also, some new Success Criteria are very hard to implement.

For example: autocomplete

With the release of WCAG 2.1, new Success Criteria were added. One of them has huge consequences for web forms: 1.3.5 Identify Input Purpose.

Some input fields now have to have an autocomplete attribute. Worldwide, this has resulted in a lot of incomprehension, and additional time and money being spent.

Plugin developers need to add the option for a proper autocomplete value, while trying to make this as understandable as possible for content managers who need to know the whys and wherefores of this Success Criterion.

The autocomplete values are very Americanised, names in Europe can be structured quite differently.

There is also an ongoing internal debate between reviewers about what to approve and what not to. Setting their own sets of criteria(!) to be able to deal with this.

Developers don’t know HTML5, let alone WCAG

Most developers live by divs and spans and do not make any effort to learn HTML5. This always amazes me and I don’t have a good explanation for it, except that developers love to copy/paste from, not always the best, resources. If it works for them, then it’s ok.

Code, found in the wild, for a button to move to the next slide in a carousel:

<li data-target="#carousel-2986" data-slide-to="1" class="carousel-indicator" role="button" title="My Cat"> <span class="sr-only">My Cat</span> </li>

This structure violates semantic HTML5 and also WCAG. But this is the kind of code reviewers see on a daily basis. This is the state of the web at the moment.

There is a huge gap between what most developers know and what HTML5 and WCAG requires.

Most frontend developers still need to be told to add a label with a for/id connection to an input field; that a placeholder is not the same as a label. Let alone knowing what an accessible name is, or how to deal with screen reader feedback on dynamic changes.

Hardly any developer knows the difference between a Guideline, Success Criterion, Understanding, Technique or what is new in 2.1. But, we expect them to.

How can we improve?

We need to focus on education and good documentation. Make both as easy and indisputable as possible.

Improve the information structure and readability on the W3C website

It would be a great help if the documentation was accessible to web creators, unambiguous and easier to maintain.

At the top of each page add a clear message when it’s outdated.
Add a link to the most recent recommendation in this message and to the WAI website. A few pages already have a message implemented, like the Accessible Rich Internet Applications (WAI-ARIA) 1.2 Working Draft. This can be done for many more.

Focus on how a web creator searches for information. Optimise for search engines. Set outdated documents to noindex, add the status and WCAG version clearly to the HTML title.

Consider this: is there a way to combine the pages about Success Criteria and the Understanding and Technique pages into one to avoid multiple pages in multiple versions about one topic?

As for the information itself: Techniques are harmful when not maintained or if they relate to outdated web techniques. Because there are so many of them, they are very hard to maintain. A system of easy-to-maintain content is needed.

Use the WAI website for education and tutorials

Instead, extend the pages on the WAI website, maintain and modernise the tutorials. Have just one place to go to instead of numerous hard to read pages with outdated information and broken links.

One place to maintain, instead of hundreds of Technique pages. This will be a lot less work in the long run and will result in information that is easier to find and of better quality for developers.

The WAI website is so valuable, I can actually send people there for readable information. It’s clear, well structured. It has a readable and appealing layout and design. It invites one to read.

The WCAG Quickref page is excellent, clear, well set up. I love it!
All the info is gathered into one page. It’s a consistent link, reliable. I can send people there. This is the starting point for disclosing all the other specifications and documentation relating to the guidelines.

Unfortunately, the Quick Reference hasn’t been updated since November 2019. So it is missing quite a few Technique additions and the removal of the Silverlight and Flash Techniques.

I hope the WAI Web Accessibility Tutorials will be modernised, extended and maintained as the place to go for developers. It would be the perfect place to directly send a developer to as a replacement for the Techniques.. But for this, too, there are over 60 open issues on GitHub at the moment. That’s such a pity.

Use the WAI pages as the place to go to for content creators and optimise them for search engines.

Let’s take a step back

We need to take a step back. Look at what we have now. For most developers, semantic HTML5 and web accessibility is unknown territory. But we require them to know the specifications and how to test.

It’s so important that they do know, because it’s a legal requirement; because more than 20% of all visitors benefit from it; because site owners do not want to lose customers or get sued.

My point is: focus first on education and on making the guidelines accessible, understandable, findable and indisputable. Wait with the WCAG 2.2 roll out. First we need to give web creators all the help they need. Because they obviously do need it.

Recommendation and discussion

What the accessibility community worldwide needs to do, in my opinion, is to help the W3C because we cannot continue like this.

Make the specifications and documentation accessible to web creators, unambiguous and easier to maintain.

Focus on how a web creator searches for information. Optimise for search engines. Add the status and WCAG version clearly to the HTML title.

Provide training, example material using modern web development techniques and links to resources. Keep them in one place on the WAI website. Information that is appealing, readable and well maintained.

Work together on the MDN Web Docs, by reviewing and adding accessible code examples for the copy/paste developers.

Remove the Techniques, as they are hard to maintain and harmful. Instead focus on making the Web Accessibility Initiative (WAI) site the place to go for Techniques and tutorials and keep all that in one place and up to date. If removing is a bridge too far, at least review and update the content.

Focus on education and documentation first, instead of writing new specifications. Stop adding new Success Criteria before the most recent ones have been properly documented and explained and better adopted into websites worldwide. Wait with the WCAG 2.2 roll out.

And most of all: think from a web creator’s point of view, because they are the ones building the web. Can I also say here: users first?

Many thanks to Adrian, Eric, Hidde, Jules and Taeke for their valuable proofreading, feedback and discussions on the draft versions of this post.