The usual sequence is that somebody decides accessibility matters, books a session for the whole company, and everybody watches ninety minutes of slides about the four principles. Six weeks later nothing has changed, and the conclusion drawn is that training does not work.
The training was fine. The timing and the audience were wrong.
Run It When There Is Something to Apply It To
Accessibility training sticks when the person leaves the room with a specific thing they are about to do differently. Which means it works best right after an audit, when there is a real list of defects in the team's own product, and worst as a standalone event with nothing following it. That is our professional position rather than a researched finding, and it is the one every practitioner we know shares.
It is also why where to start puts training in week four rather than week one, and why we tell people not to train the whole team on day one.
The strongest version
Walk the team through findings from their own site, with a screen reader running. Abstract examples get nods. Their own checkout failing gets attention.
Train by Role, Not by Company
A developer, a copywriter and a designer need almost entirely different things. Put all three in one session and most of the room is listening to material they cannot act on, which is the fastest way to teach people that this is somebody else's job.
| Role | The heart of it | Where to send them |
|---|---|---|
| Developers | Semantics, keyboard, focus, names and states | Developer checklist |
| Designers | Contrast, focus states, target size, motion | Designer checklist |
| Content editors | Headings, link text, alt text, plain language | Content editor checklist |
| QA and testers | A repeatable pass, and how to write the defect | QA test pass |
| Product managers | Scoping, prioritising, acceptance criteria | For product managers |
| Owners and directors | Which law applies, what to fund, who owns it | For business owners |
Why Training Carries So Much Weight Here
There is a reason accessibility resists being solved by tooling in a way that, say, security scanning does not, and it shows up when you line each role's material against what automated rules can reach.
Look at the designer row. Non-text contrast and focus not obscured have no rule in W3C's ACT collection, which is the published catalogue of test rules rather than a list of everything a tool can do. Target size does have one, in the same engine our free scan runs, and it measures size and spacing rather than judging whether a control was findable in the first place. Interaction-triggered animation sits at Level AAA, so it is a stretch goal rather than part of an AA audit. A designer works mostly in the part of the standard tooling reaches least, and nothing in a pipeline is coming to save that work.
The developer row has the opposite shape and the same conclusion. Name, Role, Value carries fifteen live ACT rules, more than any other criterion in the standard. Of the ten that name it as a requirement, seven test only that a name is not empty, rather than whether it describes the control. So the most heavily tooled topic on a developer's list is the one where a green result is most misleading. Focus order has no ACT rule at all.
And the content editor row is where the evidence is bluntest. WebAIM scanned the top million home pages in February 2026, and six failure types account for 96% of everything its tool detected. Two of the six are things an editor produces. Missing alt text turned up on 53.1% of home pages and empty links on 46.3%. A scan counts the defect rather than the author, and a template or a component can emit either one, so treat these as shared and assign them by looking at your own system. A third, low contrast, is shared the moment a CMS lets somebody pick a colour.
The One Thing Everybody Should See
There is a single exception to training by role, and it is worth the whole company's time: watching somebody who uses a screen reader every day try to complete a task on your product.
It converts accessibility from a compliance topic into a person having a hard time, and that conversion is what makes the rest of the training stick. How to arrange it properly, including paying participants, is in testing with disabled users.
Be clear with the room about what the session is and is not, though. It is there to change how people think about the work. It is not evidence about disabled users in general, and W3C's own guidance warns directly against assuming that what one person hit applies to everybody with a similar disability. A team that watches one session and concludes it now knows what disabled users need has learned the wrong lesson from the right experience.
Make It Outlast the Session
Whatever people remember from a session decays. What survives is what is built into the work.
- Attach a checklist to the work, in the pull request template or the definition of done. A short list at the moment of doing beats a long session last quarter.
- Put an automated check in the pipeline, so the mechanical failures never depend on memory at all. Turn it on with the rules you already pass so the build stays green on day one, then add rules as you fix them, because a check that goes red immediately gets switched off and takes the habit with it. The setup is in accessibility testing in CI.
- Name someone. Not a committee. One person who gets asked about it and who sees the failures.
- Train new starters as part of onboarding, or the knowledge leaves with the people who had it, one resignation at a time.
What Training Cannot Do
- It does not produce a conformance claim, and the standard is specific about why. A claim has to name a date, a level, the pages covered and the technologies relied upon, and nothing about a team's knowledge produces any of those. The full shape is in conformance requirements.
- It does not fix what already shipped. That is remediation, and it needs a list before it needs a lesson.
- It does not survive a process that rewards shipping fast and never asks about this. If nothing in the workflow checks, the training was a nice afternoon.
- It does not replace testing with disabled people. W3C's instruction is to combine user involvement with conformance evaluation rather than to substitute either for the other, and no amount of knowing the rules tells you how hard your interface is to actually use.
If You Are Buying It In
Ask the same questions you would ask of an auditor. Who's delivering it, do they test with assistive technology themselves, and will the session use your product or a generic example? A trainer who will not look at your site before the session is selling a talk rather than training.
Be wary of anybody who sells training as producing compliance. It is the same shape of claim a federal regulator has already acted on, when the FTC barred an overlay vendor from representing that its product makes a website WCAG-compliant without the evidence to support it. Training changes what a team builds next. It does not certify anything.
We do not sell training as a product. Our audits include a walkthrough of the findings with the team, which is the version that tends to change behaviour, and accessibility consulting answers the questions that come up afterwards, in writing, one at a time. What neither of those turns into is us doing the work, because we do not sell the building or the fixing at any price.