How to retest an accessibility fix and write useful evidence
A developer fixes an unnamed button. The next scan no longer reports it. Before closing the ticket, what should you verify?
Spots 
Repeat the original check, test the interaction, and
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. An icon-only button has no accessible name. Adding visible text makes its purpose available to users:
The label addresses the naming problem. The application
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
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
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
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.
Keyboard: Reach it with Tab and Shift+Tab. 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
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
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
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:
News
How to retest an accessibility fix and write useful evidence
A developer fixes an unnamed button.
@spots #dev
Source: Dev.to