WCAG is a pyramid scheme… in a bad way

I like that there is a growing chorus of voices pushing back on WCAG audits as the go-to source of accessibility truth.

Shhhh, it's a secret

Let's be real: secretly, as accessibility professionals, we do know handing a spreadsheet with 1000+ issues (some manual, many automated) defined in an obscure technical specification to novices is a bad plan.

But we continue to do it.

The pyramid is familiar

In college students are taught in the typical logical higher education format.

1. Lay a universal and general foundation of basic knowledge.
2. Then add a more specific layer to the topic.
3. Then another, then another, building to a pyramid of expertise.

WCAG is similar in it's principles, A, AA and AAA conformance levels.

Starting from the bottom, we have principles, guidelines, success criteria, techniques. Each criterion at each level is still designed to be as broadly applicable and generalized as possible, requiring someone initiated in the language and philosophy of the spec as a whole.

Knowing WCAG is like having a bachelors degree in architecture, and then being asked to mix and pour concrete and weld steel for a skyscraper foundation. It just… doesn't cover that.

The simplest WCAG is infuriating to apply

When I began coaching design and development teams through accessibility remediation and new product development, I immediately grew tired of explaining tabindex do's and don'ts.

Every one of us has experienced this:

Immediately after you explain WCAG SC 2.1.1, the first thing a developer does is add tabindex="0" to every single piece of content on the page in the next release.

WCAG SC 2.1.1 is one stone encased in a large pyramid. That developer is like an ant dropped onto a pyramid, and all they can see from their perspective is WCAG 2.1.1.

They obsess over 2.1.1 because that's all they are familiar with. They can make things focusable, and that's accessibility from their view of the pyramid.

Meanwhile, as professional accessibility ants, we've traversed and memorized the entire pyramid and can't believe they're so lost.

Not everyone is an academic, nor needs to be

I respect WCAG as a spec helping us define accessibility as accessibility experts, but I don't drill it into the teams I work with.

Why? WCAG can define what accessibility means for experts, but it can't describe what is accessible.

Instead, I generate accessibility acceptance criteria. This fosters a very different relationship with accessibility that product managers, designers and developers can understand.

It creates people familiar enough with accessibility to do basic things right, and to ask us smart questions about ambiguities.

Make the switch to acceptance criteria

Would you rather have a developer who can argue with you about skipping heading levels, or a team implementing solid HTML page structure.

Would you rather have a designer who designs layouts for low vision magnification tools, or a designer who argues about whether color contrast applies to hover states?

We all know which we'd choose. So why push the pyramid on them?

Acceptance criteria are not success criterion

Acceptance criteria don't create WCAG experts, and that's okay.

• Acceptance criteria tell a story anyone can understand and declare met.
• Success criterion define standards or levels which indicate whether a goal or objective has been achieved.

What's the difference?

Acceptance criteria tell a short story everyone can understand

Let's look at the keyboard only accessibility acceptance criteria for a button:

1. WHEN I use the tab key to move focus to a button
2. I SEE focus is strongly visually indicated
3. THEN when I use the spacebar and/or enter key to activate the button
4. I SEE the intended action occurs

Desktop screenreader criteria:

1. WHEN I use a desktop screenreader (NVDA, JAWS, VoiceOver)
2. AND I use the tab key to move focus to a button
3. I HEAR Its purpose is clear
4. I HEAR It identifies its role of button
5. I HEAR It expresses its state if applicable (disabled/dimmed/unavailable, expanded/collapsed, pressed, not pressed)
6. THEN when I use the spacebar and/or enter key to activate the button I HEAR the intended action occurs

Device settings criteria:

1. WHEN I use custom font settings
2. I SEE text can resize up to 200% without losing information

By working their way through the story, any designer or developer can test — without ambiguity — if the button completes this story.

WCAG success criterion define standards but only for experts

WCAG criteria have to be evaluated by experts. What do I mean by that?

To evaluate any one of these criterion, you have to become an expert in 1: the standard, 2: how to test it and 3: how to evaluate the test results.

Applicable WCAG SC for a simple text button:

• Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. - 1.4.4 AA
• The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; 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. Text that is part of a logo or brand name has no contrast requirement. - 1.4.3 AA
• All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. - 2.1.1 A
• Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. - 2.4.7 AA
• When the keyboard focus indicator is visible, an area of the focus indicator meets all the following: is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states — unless the focus indicator is determined by the user agent and cannot be adjusted by the author, or the focus indicator and the indicator's background color are not modified by the author. - 2.4.13 AAA

• For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. - 4.1.2 A
• Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. - 4.0.0 AA

At no point does WCAG discuss the spacebar or enter key. It does not mention a role of button or the tab key. A button could be focused with the F key and activated with the B key and meet these standards. Would we consider that successful?

Conclusion and next steps

WCAG is necessary as a broad spec to define what accessibility means for experts, but it can't describe what is accessible for non-experts.

I created and open sourced a way to explain accessibility without WCAG, and see plenty of teams benefitting from it.