Accessibility

Accessibility is 90% design

James Royal-Lawson

• 7 min read
A circle that is 90% whole. There is a 36 degree "slice" missing, representing 10%

A common view is that digital accessibility is something that developers and engineers will take care of. The stereotypical view of a designer's role in accessibility is getting contrast levels right.

This couldn't be further from the truth. Accessibility is the job of the designer, and most responsibility lies with design.

The W3C has a community group called ARRM - The Accessibility Roles and Responsibilities Mapping community group.

The purpose of this group is "to guide web teams (designers, developers and content creators) and subject-matter experts in successfully distributing accessibility responsibilities by roles in a web development lifecycle, so that every stakeholder understands the role that they have to play"

One of the outputs of the group is a table that maps all the WCAG 2.1 success criteria to typical roles. Roles such as content authoring, design and development. For each of the criteria, a role is marked as either expect to have primary ownership (accountable), secondary ownership (responsible), or contributing.

I've done the maths to work out who bears how much responsibility, so that you don't have to, based on the version of the ARRM WCAG success criteria mapping table published in March 2025.

I've taken a few liberties with the table that are worth mentioning, too.

The ARRM table only covers WCAG 2.1. At the time of writing, WCAG 2.2 is the latest version. This version includes 9 new criteria, and 1 has been removed. So I've made my own "best guess" mappings for the new criteria included in WCAG 2.2.

In some cases, I've based my "guess" on a closely related criterion that already existed. In a few other cases, I've made my own decision based on experience and knowledge of the criterion.

I've also grouped together UX design and Visual design. For the purposes of this article, those two roles sit on the same side of the fence - to the left of the timeline - So I'm counting them using their overall AARM role group of "Design".

The responsibility of design

There are 86 WCAG 2.2 success criteria spread across three levels; A, AA and AAA. There are 56 criteria if you just include the A and AA levels (which is normally the legal requirement, such as by the European Accessibility Act and the Web Accessibility Directive).

Across all of WCAG 2.2, design is accountable for 80% of success criteria. 69 out of 86.

Design shares the accountability for many of those criteria, but sharing accountability doesn't remove it. Design is potentially accountable for the vast majority of criteria.

If we exclude the AAA level, then design is responsible for 84% of all WCAG A and AA success criteria. 47 out of 56.

If we push this exercise to the extreme and count the criteria where design is involved in any role - either primary responsible, secondary responsible, or as a contributor then this adds another 4 criteria and the responsibility of design reaches over 90%!

A grid of 56 squares made up of 7 rows of 8 to represent all the A and AA criteria. The bottom 5 rows and the 7 of the 8 squares on the second row contain a dot. These represent the 47 criteria, 85% of all WCAG A and AA where design is responsible. There are three additional squares that containing triangles. These represent the additional 3 criteria where design is either secondary responsible or a contributor. In total 50 squares are filled, which is 91% of the 56 criteria.

Ninety percent design.

Let that sink in a moment.

Design is crucial if we aspire to make things accessible from the start.

For comparison, if we consider the success criteria where development is accountable, then it adds up to just 27 criteria. That's around 31%, rising to 32% if we exclude AAA.

Something important to note is that for almost all of those 27 criteria, development shares their primary responsibility with another role.

Development carries sole accountability for just 3 criteria, and one of those is an AAA criterion where design is a contributor (1.3.6 Identify purpose).

Which roles are responsible for criteria. Design: 80% overall, 85% excluding AAA. Dev: 31% overall, 36% excluding AAA. Content: 31% overall, 30% excluding AAA.
How much responsibility each role has for WCAG criteria. (The span shows the percentage depending on whether you consider all criteria or excluding AAA)

Our role as designers really is crucial for accessibility. For years, the call in accessibility circles has been to "shift left" and move accessibility from something done in test to something done earlier in the development process.

It's claimed that 67% of accessibility issues have their roots in design (Anna E Cook, Deque, PDF). A figure that makes complete sense when we are aware that design is responsible for up to 91% of the success criteria.

It's also claimed that fixing issues once they have made it out into production can cost 30 times more (NIST) or even as much as 100 times more (IBM). Accessibility is cheaper if it isn't retrospectively bolted on.

We, the creatives, the designers and content writers, are the ones who sow the seeds of inaccessibility. We are the ones who can change what we plant and make things accessible from the start.

James Royal-Lawson - Senior digital advisor · Designer · Digital analyst · Economist · Podcaster

I can help your organisation with accessibility, including accessibility audits, as well as boosting the accessibility skills of your design teams through training workshops and guidance. Get in touch!

References

WCAG Success Criteria
ARRM helps you assign responsibilities for digital accessibility to appropriate roles (UX designer, content creator, developer) early in projects.
Web Accessibility Initiative (WAI)W3C Web Accessibility Initiative (WAI)
European accessibility act
The European accessibility act is a directive that aims to improve the functioning of the internal market for accessible products and services, by removing barriers created by divergent rules in Member States.
European Commission
Web Accessibility
Web accessibility allows everyone, including people with disabilities, to perceive, understand, navigate and interact with the Internet.
Shaping Europe’s digital future
Shift Left
A typical software development process is sequential (1970s-1990s): define requirements, analyse, design, code, test and deploy. In this process, testing happens towards the end. Problems uncovered by testing at such a late stage can cause costly redesign and delays. The idea of Shift Left is to involve testing teams earlier in the process and to think about testing at all stages of the process.
Devopedia Foundationtintin, arvindpdmn, devbot5S
Is Closing the Web Accessibility Design/Development Gap a Bridge Too Far? | Deque
Web designers have a vision and web developers bring it to life. They’re two sides of the same coin. Everyone agrees that a world-class user experience
DequeSujasree Kurapati
The exponential cost of fixing bugs
The cost of finding and fixing defects in incredibly higher in production as compared to early stages of development — often by an order of magnitude or two.
DeepSource

Table of criteria where design is accountable

The following table lists WCAG 2.2 A and AA level criteria where design is considered accountable:

Criterion Level Name Shared with
1.1.1 A Non-text Content Content, Development
1.2.1 A Audio-only and Video-only (Prerecorded) Content
1.2.2 A Captions (Prerecorded) Content
1.2.5 AA Audio Description (Prerecorded) Content
1.3.1 A Info and Relationships Content, Development
1.3.2 A Meaningful Sequence Development
1.3.3 A Sensory Characteristics Content, Development
1.3.4 AA Orientation
1.3.5 AA Identify Input Purpose Development
1.4.1 A Use of Color
1.4.2 A Audio Control
1.4.3 AA Contrast (Minimum)
1.4.4 AA Resize text Development
1.4.5 AA Images of Text Development
1.4.10 AA Reflow
1.4.11 AA Non-text Contrast
1.4.12 AA Text Spacing
1.4.13 AA Content on Hover or Focus
2.1.1 A Keyboard Development
2.1.4 A Character Key Shortcuts
2.2.1 A Timing Adjustable
2.2.2 A Pause, Stop, Hide
2.3.1 A Three Flashes or Below Threshold Content, Development
2.4.1 A Bypass Blocks Development
2.4.3 A Focus Order
2.4.5 AA Multiple Ways Content
2.4.6 AA Headings and Labels Development
2.4.7 AA Focus Visible Development
2.4.11 AA Focus Not Obscured (Minimum)
2.5.1 A Pointer Gestures
2.5.2 A Pointer Cancellation
2.5.4 A Motion Actuation
2.5.7 AA Dragging Movements
2.5.8 AA Target Size (Minimum)
3.2.1 A On Focus Development
3.2.2 A On Input
3.2.3 AA Consistent Navigation Content
3.2.4 AA Consistent Identification
3.2.6 A Consistent Help Development
3.3.1 A Error Identification Content, Development
3.3.2 A Labels or Instructions Content, Development
3.3.3 AA Error Suggestion
3.3.4 AA Error Prevention (Legal, Financial, Data)
3.3.7 A Redundant Entry
3.3.8 AA Accessible Authentication (Minimum) Development
4.1.2 A Name, Role, Value Development
4.1.3 AA Status Messages Development

Table of additional criteria where design has a role

The following table lists the additional 3 A/AA criteria where Design has a role, but is not primary accountable:

Criterion Level Name Accountable
1.2.4 AA Captions (Live) Content
2.4.2 A Page Titled Content
2.5.3 A Label in Name Content

Table of criteria where development alone is accountable

For completeness, this final table lists the three criteria where development carries sole accountability:

Criterion Level Name Accountable
1.3.6 AAA Identify Purpose Development
2.1.2 A No Keyboard Trap Development
3.1.4 AAA Abbreviations Development

In the case of 1.3.6, Design has a contributing role.