Build a Role-Based Web Accessibility Testing Programme

A workable accessibility testing programme assigns evidence before work starts, not after a release candidate reaches QA. For every affected journey, component, template or content type, decide which checks apply, when they first become useful, who performs them, who accepts the result and who retests a fix. This prevents an automated scan from becoming false reassurance and stops the accessibility lead from becoming the person everyone waits for. The release owner receives a traceable decision record; creators retain responsibility for the quality of what they design, write and build.

What turns accessibility testing into an ongoing programme?

Accessibility testing becomes a programme when distinct evidence is produced throughout design, development, content production, QA and release preparation, with one named role accountable for accepting the evidence. W3C advises early and continuing evaluation because problems are easier to address while work can still change. A current Section508.gov RACI offers a public-sector example of distributing activities across product, design, development, content, QA, specialist and oversight roles; a business can adapt that principle without importing the source's federal duties or exact assignments.

• Automated detection finds repeatable conditions that tools can identify programmatically.
• Manual conformance checks examine operation, structure, meaning and behaviour against applicable requirements.
• Assistive-technology checks examine compatibility while trained testers complete representative tasks.
• Evaluation with disabled people investigates usability, expectations and needs that standards checks may not expose.

These forms of evidence complement one another. A clean automated result is useful, but W3C states that no evaluation tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation remains necessary. Designers should resolve accessible interaction decisions, editors should judge whether content communicates meaning, developers should verify implementation locally, and QA should conduct independent checks. The accessibility lead owns policy, coaching, methods and difficult interpretations, stepping into execution where specialist skill is genuinely required rather than performing every routine check.

How should testing depth reflect the change being released?

Testing depth should grow with interaction, reuse, novelty, journey criticality and potential user impact, while every change still produces the evidence applicable to its scope. Begin by inventorying the affected journeys, views, components, templates, documents, media, controls and supported technologies. Section508.gov programme guidance illustrates documented depth ranging from automated checks and spot checks to component and comprehensive testing, with continuous monitoring and disabled-user evaluation treated separately. The ladder below is an editorial operating model, not an official risk standard, fixed score or basis for claiming that an untested route conforms.

• Content-only change: require human content review and applicable automation; add structural, keyboard, zoom or assistive-technology review when meaning, media, documents or controls change.
• Visual or layout change: add design review and zoom or reflow checks, plus focus review wherever interactive behaviour is affected.
• Component or interaction change: define acceptance criteria before build; require developer checks, independent QA, relevant states and tasks, and regression coverage when the component is reused.
• New template, critical journey or major release: use all applicable layers, trained assistive-technology testing, representative coverage, sampled conformance evaluation and disabled-user evaluation while findings can still influence the work.

Broader conformance work needs a defined scope rather than an informal collection of convenient pages. WCAG-EM describes a process that sets the evaluation goal and scope, explores key views and functions, selects representative coverage when full evaluation is infeasible, evaluates that sample and reports the findings. Sampling supports a bounded conclusion about the declared scope; it does not justify assumptions about journeys that were excluded. Record those boundaries beside the result so reviewers can see precisely what was and was not evaluated.

What should the ownership matrix record, 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 skill and environment, retained evidence, release effect, remediation owner and retest owner. Section508.gov guidance similarly recommends defining timing, performers, depth, qualifications, environments, methods and result tracking, while its RACI and agile matrices show design, implementation, content, independent testing, defects and release evidence moving through ordinary delivery roles and artefacts. Those examples inform the handoffs below; they do not establish universal private-sector obligations.

Creators remain answerable for accessible work: designers for decisions, editors for meaningful content and developers for implementation and local checks. QA owns the test plan and independent execution, user researchers own ethical studies with disabled people, and the authorised product or release owner accepts or rejects the release. The accessibility lead stewards policy and complex interpretation. In a small team, one person may wear several hats, but the record should state which hat is active and retain trained or 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 complete meaningful tasks and inspect relevant states, not merely confirm that a tool ran or an element exists. Automation belongs in local workflows and appropriate integration pipelines, with its rules, version, scope and exclusions recorded. Human content review then judges whether page titles, headings, labels, links, instructions, error messages, captions, transcripts and text alternatives communicate useful meaning in context. WCAG 2.2 contains requirements for descriptive titles, headings and labels, link purpose and input instructions, illustrating why presence alone cannot settle content quality.

• Complete each representative task by keyboard, operate every relevant control, follow the expected focus order, enter and leave components, observe state changes and recover from errors.
• Confirm that focus is visible and not entirely obscured by author-created content; WCAG 2.2 also requires keyboard operation, subject to its path-dependent input exception, and a way to move focus away.
• Resize text to 200 per cent under the applicable WCAG criterion and its stated exceptions, checking for lost content or functionality.
• For reflow, test the 320 CSS-pixel width equivalent without horizontal scrolling and the 256 CSS-pixel height equivalent without vertical scrolling, subject to the exception for layouts requiring two dimensions for meaning or use.
• Look for obstructed information, hidden focus, controls pushed off view and unexpected off-viewport changes instead of demanding pixel-for-pixel similarity.

The finding should preserve the task context. Record the starting state, action, expected behaviour, observed behaviour, affected users, environment, evidence and owner; after remediation, repeat the affected task and nearby states that may share the same component. This makes a keyboard, content or reflow failure reproducible for the creator and reviewable by the release owner. It also prevents a narrow retest of one corrected screen from concealing a regression introduced in another state or reusable instance.

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

Add specialist evidence when representative tasks, complex interactions or higher-risk changes exceed the team's routine capability, and add disabled-user evaluation while findings can still alter the work. GOV.UK guidance recommends task-based assistive-technology testing throughout development, particularly after significant features or major changes. Select current browser, operating-system and assistive-technology combinations from audience evidence, product technology, support commitments and known risks instead of copying a universal matrix. A screen reader is one compatibility method, not a simulation of every blind person's experience or proof of conformance.

• Record the affected task and users, expected behaviour, browser, operating system, assistive technology and version, observed output, supporting evidence, remediation owner and retest result.
• Address significant obvious barriers before a disabled-user session so participants can reveal deeper usability concerns, while still seeking early prototype input where it can shape the design.
• Match the research method to the project stage, from focused prototype feedback to structured task-based evaluation, without generalising one participant's experience to a disability population.
• Combine disabled-user evaluation with standards-based conformance evaluation because each answers a different question.

W3C explains that evaluation with disabled people can expose usability issues that conformance evaluation alone may miss, but cannot by itself determine whether a website is accessible. WCAG also notes that even its highest conformance level does not make content accessible to every individual with every type, degree or combination of disability. Neither point weakens standards evaluation. Together, they show why a mature programme needs both bounded conformance evidence and direct evidence about real tasks, expectations and unmet needs.

How should evidence govern release and strengthen the programme?

Release should depend on the evidence required for the affected change class, not on one global accessibility score. The authorised product or release owner decides whether to proceed after confirming that applicable checks are complete, blocking findings are resolved and retested, and each result identifies scope, method, environment, outcome, owner, disposition and retest status. QA and accessibility specialists provide independent evidence; designers, editors and developers remain responsible for remediation. This mirrors the broader principle in Section508.gov examples that testing records, defects, release readiness and post-release feedback belong in the delivery system.

If organisational policy allows an exception, record its authorised owner, rationale, affected users, mitigation, expiry and follow-up separately. The exception does not change the failed result or establish conformance. After release, route reported barriers and recurring defects back into the ownership matrix, regression coverage, training, templates and future change classes. W3C's advice to evaluate throughout development supports this continuing loop; it does not prescribe a single score, cadence or maturity model. Programme measures should therefore illuminate incomplete evidence, repeated barriers and slow remediation rather than disguise them behind an aggregate pass rate.

1. Pilot the matrix on one critical journey and complete its evidence trail.
2. Train the named role owners and supply concise evidence templates.
3. Add appropriate automation without treating it as the acceptance decision.
4. Calibrate blocking rules against real findings and authorised organisational policy.
5. Review recurring defect patterns, improve shared components and expand coverage.
6. Use a trained evaluator for complex or disputed findings, an experienced researcher for disabled-user studies and qualified legal counsel for jurisdiction-specific interpretations.