Create a Role-Based Web Accessibility Testing Program

Turn accessibility testing into a delivery program by deciding, before work begins, which evidence a change requires, who will produce it, who can accept the result, and who must retest a fix. An automated scan attached at release review cannot answer whether a journey works by keyboard, reflows without lost content, communicates meaningful labels, or behaves well with assistive technology. Those questions belong throughout design, content, development, QA, research, and release preparation—not in one hurried specialist audit at the end.

What turns accessibility testing into a program instead of a final audit?

A testing program distributes four distinct kinds of evidence while preserving accountable acceptance. Automated detection finds repeatable, programmatically detectable conditions. Manual conformance checks examine behaviour and meaning. Assistive-technology checks test compatibility during representative tasks. Evaluation with disabled people investigates usability and unmet needs. None substitutes for all the others: W3C states that no evaluation tool alone can determine whether a site meets accessibility standards and that knowledgeable human evaluation remains necessary.

Run applicable evaluation early and throughout development or redesign, when W3C says problems are easier to address. Designers remain responsible for accessible decisions, authors for meaningful content, and developers for implementation and local checks. QA plans and independently executes applicable tests. The accessibility lead owns policy, coaching, methods, and difficult interpretations instead of becoming the default tester. Public-sector RACI guidance illustrates this distribution, but its exact assignments are examples, not universal requirements for Canadian businesses.

How should testing depth change with the work being released?

Testing depth should increase with interaction, reuse, novelty, journey importance, and potential user impact. Begin by inventorying affected journeys, components, templates, content types, documents, media, controls, states, and supported technologies. Section508.gov guidance offers a risk-based range from automated checks and spot checks through component and comprehensive testing, alongside continuous monitoring and disabled-user evaluation. The following four classes adapt that principle as an editorial model, not an official risk standard.

• Content-only change: require human content review and applicable automated checks; add structural, keyboard, zoom, document, media, or assistive-technology review when those aspects change.
• Visual or layout change: add design review and zoom or reflow checks, plus keyboard-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 for reused components.
• New template, critical journey, or major release: use all applicable layers, trained assistive-technology testing, representative coverage, sampled conformance evaluation, and timely disabled-user evaluation.

Lower risk means proportionate evidence, not permission to ignore a known barrier. Nor can a successful sample support claims about untested paths. For broader conformance work, WCAG-EM describes defining the scope and goal, exploring key views and functionality, selecting representative coverage when full evaluation is infeasible, evaluating that coverage, and reporting the findings. Record what was included and excluded so decision-makers understand exactly what the evidence supports.

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

The 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. That makes testing predictable before delivery begins and traceable when release pressure rises. Section508.gov program guidance similarly recommends defining timing, performers, depth, qualifications, environments, methods, and result tracking, though each organization must set its own operating rules.

Keep responsibility with the people creating the work while adding independent assurance. Designers own design decisions; authors and editors own content meaning; developers own implementation and local checks; QA owns the test plan and independent execution; user researchers own ethical studies; and an authorized product or release owner accepts the release decision. One person may wear several hats in a small team, but name the hat and preserve 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 each core accessibility check actually examine?

Each core check should examine a representative task and its relevant states, not merely confirm that a tool ran. Use automation for conditions it can detect consistently, record its scope and exclusions, and never treat a clean scan as a conformance decision. Human content review should judge whether titles, headings, labels, links, instructions, errors, captions, transcripts, and text alternatives communicate useful meaning in context, because presence alone does not establish quality.

• Complete tasks by keyboard, operate every relevant control, follow the expected focus order, confirm visible and unobscured focus, enter and leave components, observe state changes, and recover from errors.
• Test affected layouts for lost or obstructed information and functionality, hidden focus, unexpected off-viewport changes, and scrolling prohibited by the applicable reflow condition.
• Retain the task, page or component, environment, expected behaviour, observed result, user impact, evidence, remediation owner, and retest status.

Apply the WCAG conditions precisely. Text must resize to 200 per cent without loss of content or functionality, subject to the criterion’s stated exceptions. Reflow distinguishes content at the 320 CSS-pixel width equivalent, where horizontal scrolling is restricted, from content at the 256 CSS-pixel height equivalent, where vertical scrolling is restricted. Both conditions preserve an exception for layouts that require two dimensions for meaning or use. Review function and comprehension rather than pixel-level similarity.

When should teams add assistive-technology, disabled-user, and conformance evaluation?

Add specialist and user evidence when interaction complexity, journey importance, novelty, reuse, or potential impact demands more assurance. GOV.UK guidance recommends representative assistive-technology tasks throughout development, especially after significant features or major changes. Treat a screen reader as one compatibility method, not a simulation of every blind person’s experience or proof of conformance. Choose current combinations from audience evidence, product technology, support commitments, and known risks instead of copying a universal matrix.

• For assistive-technology findings, record the affected task and users, expected and observed behaviour, browser, operating system, technology and version, supporting evidence, remediation owner, and retest result.
• For broader conformance evaluation, define the goal and scope, explore key views and functions, select representative coverage where necessary, evaluate that coverage, and report findings and limitations.

Plan evaluation with disabled people while findings can still influence prototypes and critical journeys. Address significant obvious barriers first when practical so sessions can also expose deeper usability concerns, without postponing all involvement until the work is polished. W3C cautions against generalizing one participant’s experience and says user evaluation cannot alone determine whether a website is accessible. Combine it with standards-based evaluation: even the highest WCAG conformance level does not meet every individual need.

How should evidence control release and improve the program over time?

Release decisions should use the evidence required for the affected change class, not one global accessibility score. Required checks must be complete, blocking findings resolved and retested, and the retained record must identify scope, method, environment, result, owner, disposition, and retest status. QA and accessibility specialists supply independent evidence; creators remediate their work; and the authorized product or release owner accepts the decision under the organization’s defined policy.

1. Pilot one critical journey and complete its evidence trail.
2. Train each named performer and accountable accepter.
3. Add reusable evidence templates and appropriate automation.
4. Calibrate blocking rules against real findings and user impact.
5. Review recurring defects, then improve components, templates, training, and regression checks.
6. Expand coverage only after the first handoffs work reliably.

If policy permits an exception, record its authorized owner, rationale, affected users, mitigation, expiry, and follow-up. The exception documents a risk decision; it does not change the failed result or establish conformance. After release, feed reported barriers and recurring defects back into the matrix, training, templates, regression coverage, and future change classes. Bring in a trained evaluator for complex or disputed findings, an experienced researcher for disabled-user studies, and qualified legal counsel for jurisdiction-specific compliance interpretations.