By role · Product managers
Scoping Accessibility, and Keeping It
Nobody owns accessibility by default, which is exactly how it becomes an emergency. It usually lands here.
You own the definition of done. Put accessibility inside it and the emergency stops happening.
The pattern is common enough to plan around. A customer complains, or a prospect asks for a conformance report before signing, and accessibility becomes a project with a deadline and a budget attached. It gets fixed. Then it starts slipping again, because nothing about how the team works actually changed, and in the teams we have watched it comes back around looking like a surprise.
The fix is not a bigger project. It is putting accessibility inside the definition of done, on every story, in every sprint. Spread across every ticket it is a small tax, paid once, instead of a project paid again. What it buys is that the next supplier questionnaire stops being a fire drill.
What you own
- Accessibility inside the acceptance criteria on every story, rather than parked in an epic nobody ever pulls from.
- How findings get ranked against everything else, by what happens to a person. There is a conformance reason as well as a human one. Where a checkout is a single process, a failure on one page of it means none of that process conforms at the level you are claiming.
- Which WCAG version and level the team commits to. Content that meets 2.2 also meets 2.1 and 2.0, so the newest is the safe default rather than the ambitious one. Read the contract anyway, because a customer or a law can name an older version or add requirements of its own.
- Requiring a current conformance report from a supplier before you sign. Ask which edition and which WCAG version, because "we have a VPAT" answers neither, and no such thing as VPAT certification exists.
- Having at least one person on the team who can actually run an accessibility test, rather than a plan that quietly depends on hiring one later.
What is not yours
How any of it gets implemented, and what the law says the company owes. Those belong to engineering and to legal. What you own is making sure somebody answers both, and that the answers land inside the definition of done instead of in a document nobody opens again.
Where to start, in order
- WCAG versions and levelsHow the versions stack, and why the answer is nearly always WCAG 2.2 AA. Revisit it when a contract or a law names something else, not every quarter.
- What an audit costsWhy two quotes for the same word describe different work, and what the cheap one leaves out of scope.
- VPAT and ACRThe report your buyers ask for, the four editions it comes in, and how to read the one a supplier sends you.
- The audit report templateHow to judge a finding by what it does to a person rather than by the letter printed on the rule.
- Free scan vs. auditWhich of the two matches where your team actually is right now, and what each one leaves for you to do.
- Training your teamWhy a session with nothing to apply it to tends to fade, and what each role on your team needs instead.
- What actually gets suedWhat courts have decided, rather than the version of it in a vendor's sales deck.
The mistakes we see most from this role
Not a criticism. These are the failures that recur across audits, and knowing them is most of avoiding them.
- Running accessibility as a special project instead of putting it in the definition of done, which is how teams end up running it twice.
- Ranking findings by WCAG level instead of by impact, so a footnote nobody reads gets fixed ahead of a checkout nobody can complete.
- Buying software without asking for a conformance report first, then finding out your own team cannot use it.
- Reading a scanner report as proof of conformance, when only 10 of the 356 WCAG techniques and failures we graded are fully machine-checkable by our own count.
- Reading "Supports" in a supplier's report as "works". In the terminology the VPAT editions use, it means at least one method meets the criterion without known defects, or meets it by equivalent facilitation. "Does Not Support" means the majority of that functionality fails rather than all of it. Ask which edition the report uses, because the wording is theirs and not WCAG's.
- Writing AAA into policy, which commits the team to criteria that cannot all be satisfied for some content. That is why W3C advises against requiring AAA across a whole site.
Tools you will use
Other roles
Find out what your site actually needs.
The free scan checks 10 pages in a real browser against all 90 supported automated rules, keeps its 27 best-practice checks separate from WCAG findings, and names the rule behind every finding.