How to Build a Role-Based Web Accessibility Testing Programme

A role-based accessibility testing programme turns each change into a traceable set of decisions: what must be tested, when, by whom, with which environment, and what evidence permits release. It prevents a familiar failure in which an automated report reaches release review but nobody has completed the journey by keyboard, assessed reflow, judged whether labels make sense or named the person who will retest fixes. The operating unit is a reusable ownership matrix, not a last-minute request to the accessibility lead.

What turns accessibility testing into an ongoing programme?

An accessibility testing programme distributes distinct evidence throughout design, content production, development, QA and release preparation while preserving accountable acceptance. W3C recommends evaluating early and throughout development or redesign, when problems are easier to address. That means designers check decisions before handover, authors review meaning before publication, developers test implementation locally, QA independently exercises affected journeys, and an authorised product or release owner decides whether the assembled evidence is sufficient.

The programme should distinguish four evidence types. Automated detection finds repeatable, programmatically detectable conditions; manual conformance checks examine behaviour and meaning; assistive-technology checks examine compatibility during representative tasks; and evaluation with disabled people investigates usability and unmet needs. No evaluation tool alone can determine whether a website meets accessibility standards, so a clean scan is useful evidence rather than a verdict. Public-sector RACI guidance demonstrates distributed ownership, but its exact assignments are an example, not a private-sector requirement.

How should testing depth reflect the change being released?

Testing depth should grow with affected interaction, reuse, novelty, journey criticality and potential user impact. Before choosing methods, inventory the changed journeys, components, templates, content types, documents, media, controls and supported technologies. The following four classes are an adaptable editorial model, not an official risk standard or fixed scoring system. Every class still requires applicable evidence, and a narrow test scope cannot justify a broad conformance claim.

• For content-only work, require human content review and applicable automated checks; add structural, keyboard, zoom or assistive-technology review when meaning, media, documents or controls change.
• For visual or layout work, add design review and zoom or reflow checks, plus focus review wherever the change affects interactive behaviour.
• For a component or interaction, define acceptance criteria before build, require developer checks and independent QA, cover relevant states and representative tasks, and add regression checks when reused.
• For a new template, critical journey or major release, use all applicable layers, trained assistive-technology testing, representative coverage, sampled conformance evaluation and timely evaluation with disabled people.

The matrix should record why a class was selected and precisely what it covers. Section508.gov illustrates depth ranging from automated and spot checks to component and comprehensive testing, alongside continuous monitoring and usability work; the organisation must adapt that principle to its own context. Where broader conformance evaluation is required, WCAG-EM provides a separate process: define scope and goal, explore key views and functions, select representative coverage where necessary, evaluate it and report the findings.

What belongs in the ownership matrix, and who owns each handoff?

The ownership matrix should give every test layer a trigger and scope, earliest useful stage, responsible performer, accountable accepter, required expertise and environment, retained evidence, blocking rule, and remediation or retest owner. This structure makes the required evidence predictable before work starts and the acceptance decision traceable afterwards. Section508.gov guidance similarly connects timing, performers, depth, qualifications, environments, methods and result tracking, while its agile matrix places accessibility evidence inside ordinary delivery artefacts.

Creators remain responsible for their work: designers for accessible design decisions, authors and editors for meaningful content, and developers for implementation and local checks. QA owns the test plan and independent execution; user researchers plan ethical work with disabled people; the accessibility lead owns policy, coaching, methods and difficult interpretations; and the authorised product or release owner accepts release risk. In a small team, one person may wear several hats, but the record should name each hat and preserve independent review for higher-risk work.

Accessibility stops being somebody else's final check when every change arrives with named evidence, ownership and a retest path.

What should the core accessibility checks examine?

Core checks should examine complete tasks, meaningful content and relevant states rather than merely confirming that a tool ran. Automation belongs in local workflows and appropriate integration pipelines, with its scope and exclusions recorded. Human content review asks whether titles, headings, labels, links, instructions, errors, captions, transcripts and text alternatives communicate useful meaning in context. WCAG includes requirements involving precisely such human judgements, so technical presence alone is insufficient.

• For keyboard review, operate every relevant control, follow the expected focus order, confirm visible and unobscured focus, enter and leave components, observe state changes, recover from errors and complete representative tasks.
• For text resizing, check the applicable WCAG requirement at 200%, subject to its stated exceptions, and record any loss of content or functionality.
• For reflow, distinguish content at the 320 CSS-pixel width equivalent without horizontal scrolling from content at the 256 CSS-pixel height equivalent without vertical scrolling, subject to the two-dimensional-layout exception.
• Across zoom and reflow, look for lost, hidden or obstructed information and functionality, concealed focus and unexpected off-viewport changes rather than demanding pixel similarity.

A keyboard pass must go beyond pressing Tab a few times. WCAG requires functionality to be operable through a keyboard interface, subject to its path-dependent input exception, and users must be able to move focus away from components. At Level AA, focus must be visible and author-created content must not entirely obscure the focused component. Record the task, starting state, expected behaviour, observed result and evidence so another tester can reproduce the failure and verify the repair.

When should specialist, assistive-technology and disabled-user evidence be added?

Teams should add trained assistive-technology testing for representative tasks, relevant states and higher-risk changes, and evaluation with disabled people when findings can still influence prototypes or critical journeys. GOV.UK guidance recommends task-based assistive-technology testing throughout development, particularly after significant features or major changes. A screen reader is one compatibility method: it is neither a simulation of every blind person's experience nor proof that a product conforms.

Choose current browser, operating-system and assistive-technology combinations from audience evidence, product technology, support commitments and known risks rather than copying a universal matrix. Each finding should identify the affected task and users, impact, expected behaviour, browser, operating system, technology and version, supporting evidence, remediation owner and retest result. Those details make prioritisation and reproduction possible; a screenshot without steps, task context or relevant output is rarely an adequate record.

Evaluation with disabled people can expose usability issues that standards-based evaluation misses, but it cannot by itself determine whether a website is accessible. Address significant obvious barriers before sessions so participants can also reveal deeper concerns, without postponing useful early prototype feedback. Match the research method to the project stage, from focused prototype review to formal task studies, and never generalise one participant's experience to a disability population. Combine this evidence with conformance evaluation: even the highest WCAG level cannot meet every individual's needs.

How should evidence govern release and improve the programme?

Evidence should control release through the requirements of the affected change class, not one global accessibility score. Before approval, confirm that every applicable check is complete, blocking findings have been resolved and retested, and each retained result identifies scope, method, environment, outcome, owner, disposition and retest status. QA and accessibility specialists supply independent evidence, creators remediate their work, and the authorised product or release owner makes the acceptance decision.

If organisational policy permits an exception, retain the authorised owner, rationale, affected users, mitigation, expiry and follow-up action. The exception remains separate from the underlying test result and does not establish conformance. This gate is a practical governance model, not certification or legal advice. Bring in a trained evaluator for complex interactions, disputed findings, assistive-technology behaviour or representative conformance coverage, and obtain qualified legal advice for jurisdiction-specific compliance interpretations.

1. Pilot the complete matrix on one critical journey.
2. Train every named role owner in their checks and evidence duties.
3. Add reusable evidence templates and appropriate automation.
4. Calibrate blocking rules through real release decisions.
5. Review recurring defects, reported barriers and missed handoffs.
6. Expand coverage while updating training, templates and regression checks.

After release, feed reported barriers and recurring defects back into the ownership matrix rather than reducing progress to a single pass rate or maturity score. A repeated label problem may require stronger author guidance; a recurring focus defect may need a component repair and regression check; a late research finding may expose a missing trigger. W3C's advice to evaluate throughout development supports this continuous loop, while public-sector task matrices show how defect records, release evidence and post-release feedback can remain connected.