A developer fixes an unnamed button. The next scan no longer reports it. Before closing the ticket, what should you verify?
Repeat the original check, test the interaction, and record the evidence. This fictional checkout example shows a focused retest workflow you can use in your existing issue tracker.
Start with one clear fix
An icon-only button has no accessible name. Adding visible text makes its purpose available to users:
<!-- Before -->
<button type="button" id="checkout">
<svg aria-hidden="true" focusable="false"><!-- Cart icon --></svg>
</button>
<!-- After -->
<button type="button" id="checkout">
<svg aria-hidden="true" focusable="false"><!-- Cart icon --></svg>
Continue to checkout
</button>
Enter fullscreen mode Exit fullscreen mode
The label addresses the naming problem. The application still needs to handle activation correctly. W3C’s button pattern describes naming, keyboard activation and focus behavior.
1 Repeat the automated check
Open the same page and state, such as a cart containing an item. Record the original and updated build identifiers. Keep the engine version and scan settings comparable, or document what changed.
Confirm the retest completed and included the affected button. An empty cart, missing component or failed scan cannot verify the fix.
A useful result is specific: “The accessible-name finding was not detected for the checkout button in the populated-cart state.” Use that wording only when your evidence supports it. Keep both reports so another reviewer can compare them.
2 Test the interaction
For this button, check:
- Keyboard: Reach it with Tab and Shift+Tab. Check visible focus and navigation order. Test Enter and Space separately from the same starting state; each should perform the intended action once.
- Screen reader: Check the announced name and button role. Record the browser, screen reader and versions used.
- Resulting state: Follow the checkout action. If it opens a dialog, check focus inside it and after closing it. Exercise applicable loading and error states, including how the user recovers.
These checks verify a specific interaction. They do not establish whole-site accessibility. W3C explains why automated tools need human evaluation.
3 Keep the evidence with the ticket
Record each check as passed, failed or not tested according to what you actually verified. These statuses describe the page assessment. Keep automated results and manual observations separate.
Use this compact template:
Page, component and starting state:
Original issue and evidence:
Expected behavior:
Fix build or commit:
Retest date and reviewer:
Browser and assistive technology versions:
Scan engine, settings and result:
Keyboard and screen-reader observations:
Other states checked and coverage gaps:
Remaining issues and linked tickets:
Decision against acceptance criteria:
Enter fullscreen mode Exit fullscreen mode
If the label is fixed but focus remains broken, record that remaining issue and assign it. Close the ticket against its acceptance criteria, with enough detail for another tester to repeat the check. Redact personal information and secrets before sharing evidence.
Put the workflow to use
I maintain GatekeeperQA. GatekeeperQA is ready to use for accessibility reporting and retest tracking, with findings, reviewer notes, ticket copying and retest comparisons.
Explore the free interactive sample without signing up, or scan a public page you own or have permission to test. Usage and shared-capacity limits apply.
Try it in your workflow. Your feedback helps shape what we build next.
Disclosure: Drafted with AI assistance. This fictional example is not a client assessment.