Accessibility in your team: setting up roles and sign-offs

Set a goal you can verify

“We're improving the website” is hard to plan. Instead, define a clearly scoped assignment: “We test sign-up and the contact form against our defined WCAG target, fix blocking barriers and document the open points.” Name the target standard, the offerings covered, the time available and the next test date. You also need to classify the legal requirements for your specific offering appropriately.

Also note which areas are outside the scope of the test for now. This makes a narrowly defined test assignment traceable; it does not turn it into a statement about the entire website.

Name tasks, not just one responsible person

One coordinating person keeps the overview. The work is still shared: design checks contrast and states, the editorial team checks structure and texts, development checks semantics and interactions. The person responsible for the subject matter confirms that a changed process still serves its purpose. In a small company, several tasks may fall to the same person; they should still be named explicitly.

Agree with external agencies and component suppliers who accepts a finding, delivers the fix and documents the retest. An unclear handover point leaves even a well-described error lying untouched.

Prioritise by impact

Start with barriers that prevent an important task: an order button that cannot be operated, an incomprehensible form error or navigation without keyboard access. Shared components deserve special attention, because fixing them improves many pages. Take reported problems and heavily used content into account.

One possible order is: blocked completion, severely hindered operation, further improvement. Add the affected task, reach and effort to each one. A high number of similar findings should not automatically overshadow a single process that breaks off completely.

Turn findings into actionable tickets

1. 1Name the URL or component and the task someone wants to complete.
2. 2Describe the starting state, test steps, observed behaviour and expected result.
3. 3Add the test environment and, where relevant, the WCAG reference and a screenshot or output.
4. 4Assign a responsible person, a priority and a realistic deadline.
5. 5Only close the ticket after retesting the same process, and document the result.

Build testing into sign-off

Set a short editorial check for new pages and a suitable manual test for new components. Automated checks can surface recurring technical problems early. Plan more extensive testing for new or significantly changed processes. A small, fixed set of test tasks makes it easier to compare releases.

Involve people with different disabilities early and plan time and fair pay for this. Their feedback explains real-world barriers to use. It complements testing against the standard but does not replace it.

Report progress clearly

Report which tasks were tested, which barriers have been fixed and what is still open. For open points, add who is responsible and the next step. A single score leaves these questions unanswered. Collect feedback through a contact people can reach and look for recurring causes: is a suitable component, an editorial template or knowledge in the team missing? This leads to targeted improvements for the next round of work.