Who does what, and when, so accessibility isn't left to the end

The W3C's planning guide sets out the decisions to make first:

• The target. At a minimum, the policy states "what web accessibility standard you aim to conform to and by when". Write it into the contract and into the definition of done. The law or a contract may set the level; what it takes for a page to conform to WCAG covers what a level requires.
• The owner. "Responsibility for delivering accessibility needs to be assigned to specific individuals and incorporated into their job description", which gives them the time and the training. One named person decides when the target and the schedule clash.
• The budget. Reviews, training, audits and testing with users, each with time in the schedule. A budget with no time to fix what the audits find buys a report, not a site.
• The training. For each role what it needs: the W3C lists accessible visual design for designers, accessible coding for developers and testers, and writing accessible content for content authors.
• What you buy. Components, widgets and platforms bought in are part of the site. Ask for their accessibility before signing, as reading a vendor's VPAT before you buy, and what to ask next explains.

The definition of done turns the target into checks a story has to pass. A short one, the same for every story:

• It is built from design-system components, or adds new ones with their own accessibility tests.
• The automated checks in CI report no new failures.
• Every control works with a keyboard alone, in an order that matches the screen, with a visible focus indicator.
• The story's task works with the screen reader and browser the team agreed on.
• It works at 200% zoom and at 320 CSS pixels wide.
• Its headings, link text, labels and text alternatives have been reviewed.

Most of what an audit finds on a finished site is the same few components failing on every page. So build and test the shared parts before the pages that use them. The W3C's implementation guide advises prioritising "the development of accessible templates and components to support the creating of accessible content", and its planning guide makes maintaining "code libraries with accessible components" a development responsibility.

• Buttons: a native button as the component library's default, so no page gets a div that Tab never reaches, as in div buttons that can't be reached with Tab.
• Focus: one focus indicator in the design system's tokens, so a reset can't remove it page by page, as in missing focus indicators on custom buttons.
• Form fields: a label as a required property of the shared field component, with the for and id generated together, as in form fields with missing or mismatched labels.
• Dialogs, menus, tabs: the interactive patterns, each with its keyboard behaviour written into the component, not into each page.

Designers hand over more than pictures: the W3C maturity model's proof points include design deliverables that carry accessibility information and annotations, such as the heading structure, the focus order, each control's name and its states. Content authors write the headings, link text and text alternatives the components can't.

The W3C's advice is to "Find and fix issues early in the process to reduce risk and cost", and to fold the checks into the testing the team already does rather than run them separately. Where the checks go depends on how the project runs:

Way of working	When accessibility is checked	What a late find costs
Waterfall	Requirements and designs reviewed against the target, then one test phase after the build	A problem in a shared component surfaces when every page uses it; the fix reopens design, code and test
Agile	In each story's definition of done, every sprint, and in a fuller review at milestones	A problem surfaces in the sprint that made it, while the code is fresh
Continuous delivery	Automated checks on every change, and a documented cadence of manual tests between releases	A change ships with the checks it passed, and the manual cadence catches the rest

In each of them, 3 kinds of test do different jobs:

• Automated checks in CI, on every pull request. They catch missing names, invalid ARIA, contrast in code and similar failures cheaply and every time, and they can't judge most of the rest, as what automated checks miss explains.
• Manual tests, every sprint, on the new components and on the key tasks: keyboard alone, a screen reader, zoom and reflow. This is where focus order, announcements and whether a task can be finished get checked.
• Regression tests, for what already works. A component's tests check its name, role, states and keys after every change; before each release, the key tasks are run again by hand. A release gate keeps a known blocker from shipping because nobody stopped it.

Testing with disabled people finds what none of these do, as what testing with disabled people finds that an audit doesn't explains, and is worth a place in the plan from the first prototype.

The W3C's roles mapping names the roles involved in accessibility; the planning guide adds purchasing and acceptance testing. In a project, each owns a part:

Role	Owns
Management and governance	The policy, the target and its date, the budget, and a named owner
Product owner	Acceptance criteria, the priority of accessibility bugs, and the definition of done, agreed with the whole team
Project manager	Estimates and a schedule that include accessibility work and testing
User experience researcher	Disabled participants in research and testing
User experience designer	Structure, focus order and keyboard interaction, annotated for developers
Visual designer	Contrast, focus indicators, and states that don't rely on colour alone
Content author	Headings, link text, text alternatives, captions and plain wording
Front-end developer	Semantic HTML, accessible components, names and states
Back-end developer	Error messages, time limits and the data that shapes what a page can say
Quality assurance	Automated and manual tests, regression tests, and tracking accessibility bugs
Purchasing and contracts	Accessibility requirements in contracts for anything bought in
Support	A way for people to report barriers, and a route to the team that fixes them

Launch is when the site starts changing without the project team. "Changing content can introduce accessibility issues", and the W3C's advice for sustaining the work is:

• Check at publishing. "Include accessibility checks within the publishing process to help reduce the risk of issues occurring", in the CMS and in the author's own review.
• Review regularly. "As your website content changes, ensure that regular accessibility reviews are performed", and ask why each issue happened: training, a CMS change, or an unclear process.
• Retest releases. Keep the CI checks and the regression tests running on every release; the maturity model's highest level includes maintenance releases that are re-inspected for accessibility.
• Listen. "Invite user feedback", train first-line support to handle it, and tell the person who raised an issue when a fix is expected. The accessibility statement is where people find that route, as in accessibility statements that are missing or say nothing.