How to Verify an Accessibility Fix

A developer marks an issue "fixed." Is it? Completing a change and verifying that the barrier is gone are different steps, and skipping the second one is how teams end up with resolved tickets over unresolved problems. Verification is the check that closes the gap between "we changed something" and "the issue is actually fixed."

Step 1: Reproduce the original issue

You cannot confirm a fix you cannot reproduce. Before checking anything new, go back to the original finding and demonstrate the problem: the unlabeled field, the unreachable button, the missing alt text. This tells you exactly what success looks like and guards against verifying the wrong thing.

A quick example used throughout this article: a scan flags the email field on a checkout page for having no label. A keyboard or screen reader user hears no announced purpose for the field. That is the issue to reproduce.

Step 2: Check the deployed change

Confirm the change actually shipped to the page in question, on the environment users see. Fixes stall in staging, get reverted by later commits, or apply to one template while the flagged page uses another. Look at the live page and inspect the element the finding named.

In the example: the developer added a visible label programmatically associated with the email input. Open the checkout page and confirm the label is rendered and linked to the field.

Step 3: Rerun the relevant automated checks

Rerun the check that found the issue, scoped to the affected page or component. If the finding came from a scan, a targeted rescan confirms whether the rule violation is gone.

One caution applies in both directions. A finding that disappears from a rescan is not automatically verified: the element may have been moved, renamed, or removed rather than fixed. And a rescan that still flags the issue may reflect a different cause than the original. The automated result is evidence to read, not a verdict to accept blindly.

Step 4: Test the way users experience it

Automated checks confirm the code changed. They cannot confirm the experience improved, and that is what the finding was actually about. Match the manual check to the barrier:

• Keyboard checks for anything interactive: can you reach it, operate it, see focus, and escape it?
• Assistive technology checks for anything semantic: does a screen reader announce the field's purpose, the button's name, the error that occurred?
• Task-level checks for flows: can the journey that was blocked now be completed end to end?

In the example: tab to the email field and confirm focus is visible and the label is announced. If a screen reader is available, listen for the announced purpose. The W3C's Easy Checks is a practical starting point for this kind of review.

Step 5: Check for regressions around the fix

Fixes share templates. Adding the label may have changed the checkout form's other fields, or the same unlabeled field may exist on a second template the scan did not cover. Check the pages and components related to the fix, not only the flagged page. A verified fix that broke something next door is not a finished fix.

Step 6: Record the verification

Write down who checked, what they checked, how, when, and what they found. "Priya S., March 9: rescanned the checkout page, walked it by keyboard, confirmed the label is rendered and announced; result: verified" is a complete entry. It distinguishes a finished fix from a claimed one, and it is what makes the record meaningful later.

What verification is not

Verifying one fix verifies that fix. It says nothing about the rest of the page, other pages, or the site as a whole, and it is not a conformance judgment or a compliance certification. It is one honest, recorded step in a larger routine. The remediation checklist shows where verification fits in the full cycle, and Why Accessibility Needs Ongoing Monitoring covers how to keep verified work verified as the site changes.

In SiteRecord, findings move to a ready-to-verify state after a correction is recorded, and verification entries capture who checked, the method, and the result, so "change completed" and "fix verified" stay visibly separate on the record.