Write a definition of done for outsourced accessibility fixes

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Start from the reported barrier, not the code

An accessibility fix should begin with the user action that fails and the technology that exposed it. Record the page, the control, the input method, and the expected result. A ticket that says the form is inaccessible gives the engineer nothing to verify. The barrier description is the acceptance criterion.

Ask the reporter to include the assistive technology and version, the browser, and the steps that lead to the failure. If the report came from an automated scan, reproduce the finding with a real interaction before writing the fix. A scanner can point to a rule, but it cannot confirm that the user can complete the task. If the report came from a customer, ask support to collect the same details before the ticket reaches engineering.

Write the expected behavior for each input method

Accessibility is not one behavior, so the definition of done should cover keyboard, screen reader, zoom, and pointer input where they apply. State what the user should be able to do with each method. For a modal, that might mean focus moves into the dialog, the escape key closes it, and focus returns to the trigger. Each behavior is a testable line.

Include the visual requirements that affect the interaction, such as focus visibility and contrast. A control that works with a keyboard but has no visible focus is still difficult to use. Record the expected focus style and the contrast target. The reviewer should not have to infer the standard from a design file.

Require evidence from a real assistive technology

An automated scan is a useful first pass, but it does not prove that a screen reader announces the control correctly. Require a short recording or a written transcript of the screen reader interaction. Include the browser, the screen reader version, and the exact steps. The evidence should show the before and after states.

Keyboard testing should show the full path, including the escape route and the focus return. Zoom testing should show the layout at the target magnification without horizontal scrolling for the main task. If a test cannot be performed, record the gap and the owner who accepted it. A definition of done that allows untested claims is not a standard.

Separate a code fix from a content fix

Some barriers are caused by markup, and some are caused by the words or the structure of the content. A missing label may be a code fix, while an ambiguous error message may be a content fix. Decide which kind of change is needed before assigning the work. Mixing the two in one ticket makes the acceptance unclear.

If the fix requires a design decision, such as a new focus style or a different layout, route it to the design owner. The engineer should not invent a visual standard that the product has not approved. Record the decision and the reason so the next component follows the same pattern. A one-off fix that is not reflected in the system will recur.

Check the regression surface

A shared component change can affect every page that uses it, so the definition of done should name the regression surface. List the screens and flows that reuse the component and add them to the test plan. If the component is used in a checkout or a login flow, include the full task, not only the component. Name the regression pages in the ticket before the change is merged.

Run the regression check with the same assistive technology used for the original report. A fix that works on the reported page but breaks another page is not done. Record the pages tested and the result. If a page could not be tested, say so and name the risk.

Record what was not fixed and why

Not every barrier can be fixed in the same release, and pretending otherwise damages trust. Record the items that remain, the reason, and the owner who accepted the deferral. Include the user impact and the planned date if one exists. A transparent backlog is better than a closed ticket that hides the problem.

If the deferral is due to a dependency or a vendor, name it and the date it will be reviewed. If the deferral is due to a design decision, record the decision and the person who made it. The next reviewer should be able to see why the item is still open without reopening the whole investigation. Review the deferral at the next accessibility meeting rather than leaving it in a closed sprint.

Get acceptance from the owner, not only the developer

The engineer can confirm that the code changed, but the product owner or accessibility lead should confirm that the barrier is gone. Ask that person to run the same task with the same assistive technology. Record their confirmation and the date. This step prevents a technically correct change from being accepted when the user experience is still broken.

If the owner cannot test, provide the recording and a short script so they can repeat it. Do not accept the developer's summary as the only evidence. The acceptance record should name the person, the method, and the result. That record is what makes the definition of done meaningful.

Re-test after the next release

Accessibility regressions often appear after a later change to the same component or design system. Add the fixed flow to the regression suite and re-test it after the next release. Use the same assistive technology and the same task. Record the result beside the original fix.

If the regression returns, reopen the item and link it to the change that caused it. If the fix holds, note the release and keep the test in the suite. Review the pattern at the next accessibility review and update the component guidance. A fix that is not re-tested is a temporary repair.

Frequently asked questions

Sources

1. W3C Web Content Accessibility Guidelines 2.2

   Success criteria used to define the expected behavior.

2. W3C WAI, testing with screen readers

   Guidance on assistive-technology evaluation.

3. WebAIM, keyboard accessibility

   Practical keyboard and focus testing guidance.