Digital Accessibility Training Is the Bottleneck: Using the W3C Maturity Model to Build the Team the EAA Assumes You Have

Accessibility tooling has never been better. Accessibility outcomes have never been worse.

The 2026 WebAIM Million found 95.9 percent of the top one million home pages carried detectable WCAG failures, up from 94.8 percent a year earlier. Detected errors averaged 56.1 per page, a 10.1 percent increase, reversing several years of slow improvement. The report's own explanation is the interesting part: average page element counts hit 1,437, up 22.5 percent in a single year and nearly double the 2019 figure.

Read those two numbers together and the diagnosis is uncomfortable. Pages are being built faster and more elaborately than the people building them are being taught to build them accessibly. No scanner fixes that. The constraint is not detection. It is trained humans, and the organisational structures that keep them trained.

This post is about closing that gap: what accessibility training should actually contain for each role, and how to use the W3C Accessibility Maturity Model to turn scattered training into a programme a regulator can see.

Why training is now a compliance artefact, not an HR line item

Three things changed at once.

The EAA made accessibility a continuing obligation, not a project. A service that conformed on launch day and regressed over eighteen sprints is non-conformant. Sustained conformance requires people who make accessible decisions by default, because there is no review gate wide enough to catch everything a team that has not been trained will ship.

Market surveillance authorities ask about process. Enforcement across the EU has moved past "is this page broken" towards "how does this organisation ensure it is not". Sweden's PTS has opened supervisory cases and published an audit programme; France's DGCCRF pursued major retailers through the courts; Italy's AgID issued private-sector guidance in March 2026. These are process-literate regulators, and training records are process evidence.

The draft of the next standard is moving the same way. WCAG 3's current draft includes assertions: documented organisational claims, sitting alongside technical requirements, about things like training and testing practice. That draft is years from being law anywhere. The direction of travel is not ambiguous.

There is also a plain labour-market reality. The accessibility profession is small relative to demand, respondents to WebAIM's global salary survey averaged 9.5 years of experience, and full-time salaries averaged $101,688. You will not hire your way to conformance across a large engineering organisation. You will have to teach the people you already employ.

Training that actually changes what ships

Generic "accessibility awareness" sessions have a poor return. What works is role-specific, task-anchored teaching that changes a decision the person makes in their normal week. Five curricula, in rough priority order.

Designers

The highest-leverage audience, because a design decision propagates to every implementation of it and costs nothing to get right at the point of creation.

• Colour contrast as a working constraint: 4.5:1 for body text, 3:1 for large text and for UI components and graphical objects. Check at palette definition, not at handover.
• Visible focus: designing focus indicators that survive the dark-mode variant and the brand review.
• Touch target size and spacing.
• Specifying accessible names, headings hierarchy, and reading order on the artboard rather than leaving them to be inferred.
• Error states, required-field marking and instructions that do not rely on colour or placement alone.
• Motion: designing a reduced-motion variant as a first-class state.
• Cognitive load: plain language, consistent navigation, avoiding cognitive-function tests in authentication.

Front-end engineers

• Semantic HTML first, and the first rule of ARIA: do not use ARIA when native HTML will do.
• Accessible names: how they are computed, and the common ways they end up empty or wrong.
• Keyboard interaction patterns for custom components, and how to avoid keyboard traps.
• Focus management in modals, drawers, route changes and dynamic content.
• Forms: label association, grouping, error messaging, autocomplete.
• Live regions, and their frequent misuse.
• Running axe-core locally and reading its output critically.

QA and test engineers

• A repeatable screen reader testing protocol that produces comparable results release to release, rather than ad hoc exploration.
• Which assistive-technology and browser pairings to cover, and in what order.
• Keyboard-only journey testing as a standard regression pass.
• Writing accessibility defects that a developer can act on: criterion, impact, reproduction, location, severity.
• Where automation genuinely ends, so that a green pipeline is never mistaken for conformance.

Content authors and marketers

Usually the largest population and the most neglected, and they touch the pages regulators land on first.

• Alt text by image purpose, including when the correct alt text is empty.
• Heading structure in the CMS, and why visual styling is not structure.
• Descriptive link text.
• Accessible tables, and not using tables for layout.
• Captions, transcripts and audio description obligations for media.
• Accessible documents, especially PDFs, which fail at extraordinary rates.

Product owners, procurement and legal

• What EN 301 549 and WCAG 2.1 AA actually require, and what they do not.
• Reading an accessibility conformance report or VPAT critically rather than filing it.
• Accessibility acceptance criteria in user stories and definitions of done.
• Contractual accessibility clauses and supplier remedies, since third-party components remain your liability.
• When the disproportionate burden argument is available, what Annex VI demands to support it, and why weak claims invite scrutiny.

Two design principles for all five: teach against your own codebase and your own defect history rather than generic examples, and make every session end with a change to a checklist, template, component or definition of done. Training that does not modify an artefact evaporates within a quarter.

From training sessions to a programme: the W3C Accessibility Maturity Model

Training on its own produces a sawtooth: capability rises after each cohort and decays as people move on. A maturity model is how you convert that into a ratchet.

The W3C Accessibility Maturity Model, developed through the W3C's Maturity Model Task Force and published as a Group Draft Note, sets out a framework for measuring and improving how an organisation addresses digital accessibility. Rather than a pass or fail score, it examines the operational capabilities that support long-term success, assessed through dimensions and documented with proof points.

It defines seven dimensions:

1. Communications - how accessibility is communicated internally and externally.
2. Culture - leadership commitment and whether accessibility is treated as shared responsibility or as one team's problem.
3. ICT Development Life Cycle - whether accessibility is embedded across design, build, test and release.
4. Knowledge and Skill - the level of accessibility training, expertise and resources available to staff and leadership.
5. Personnel - roles, responsibilities and whether accountability is named.
6. Procurement - how accessibility requirements enter supplier selection and contracts.
7. Support - how accessibility issues raised by users and staff are received and resolved.

Two features make it useful rather than decorative.

Proof points force evidence. A dimension is not self-assessed on vibes. It is evidenced with artefacts: the training curriculum and completion records, the procurement clause, the named owner, the ticket queue and its resolution times. This is the same evidence a market surveillance authority requests, which means maturity assessment and regulatory readiness are the same exercise done once.

Dimensions have owners. The model expects a named leader responsible for the key aspects of each dimension. That single structural demand solves the most common failure in accessibility programmes, which is that everybody agrees accessibility matters and nobody is accountable for any specific part of it.

Note the model's status honestly: it is a W3C Group Draft Note rather than a Recommendation, and it competes with several vendor and consultancy maturity models. Nothing obliges you to use it. Its advantage is that it is public, vendor-neutral, free, and grounded in the same standards ecosystem your EAA obligations already point at.

Running the assessment without it becoming a consultancy project

A workable first pass takes two to three weeks internally.

Week one: evidence sweep. For each of the seven dimensions, collect what already exists. Training records. Design system accessibility documentation. CI configuration. Procurement templates. The accessibility statement. Your last audit and what happened to its findings. Most organisations discover they are stronger on ICT Development Life Cycle than on Procurement or Support, because the former has engineering advocates and the latter two have nobody.

Week two: score and evidence. Rate each dimension against the model's levels and, critically, attach the proof point or record its absence. "We think we are intermediate on Knowledge and Skill" is worthless. "Fourteen of forty-one front-end engineers have completed accessibility training; no designer has; no record exists for content authors" is a plan.

Week three: pick two dimensions and name owners. Not seven. Two, with a named leader each, a twelve-month target and a quarterly review. Accessibility programmes die of breadth far more often than of insufficient ambition.

Then re-assess annually, and keep the previous assessment. A trajectory across two or three years is far more persuasive to a regulator, a board or an enterprise customer's procurement team than any single snapshot, because it demonstrates a functioning process rather than a good quarter.

What good looks like in twelve months

A realistic target for an organisation starting from scattered effort:

• Every designer and front-end engineer has completed role-specific training, tracked, with new joiners covered in onboarding.
• Content authors have short, task-specific training tied to the CMS they actually use.
• Accessibility acceptance criteria appear in the definition of done, and a component is not added to the design system without a documented accessible pattern.
• Automated checks run in CI on every pull request, with the explicit shared understanding that passing them is necessary and not sufficient.
• A documented screen reader testing protocol runs each release.
• Procurement templates carry accessibility requirements and require conformance evidence from suppliers.
• One named person owns each of the seven dimensions, even where the honest current state is "nothing yet".
• The maturity assessment has been run twice, and the second one is better.

None of that requires hiring a specialist team. It requires deciding that accessibility capability is something the organisation builds rather than something it buys per audit.

The argument to take to your board

The business case writes itself from two numbers already in this post.

Accessibility errors rose 10.1 percent in a year while page complexity rose 22.5 percent. Whatever your organisation is currently doing, if it does not scale with complexity, your exposure grows every sprint by default.

And the professionals who could be hired to fix that are scarce, experienced and expensive. The realistic path is capability inside the teams you have.

An audit tells you where you are today. Training and maturity work determine where you will be at the next audit. Only one of those is an asset.