Check semantics and keyboard behavior
Inspect whether navigation uses links and actions use buttons. Move through the page with the keyboard and confirm that focus is visible and follows a useful order. Open and close dialogs, checking that focus reaches their controls and returns to a sensible place.
These are starting checks. Automated scanners and a successful keyboard pass do not establish full accessibility conformance. Review the complete flow with the assistive technologies and user needs relevant to the project.
References: W3C: WCAG 2.2 quick reference
Measure contrast on the actual surface
WCAG 2.2 AA calls for at least 4.5:1 contrast for ordinary text and 3:1 for qualifying large text, with specified exceptions. Measure the actual foreground/background pair, including text over images and hover states. A palette name such as accessible blue is not a measurement.
If a disabled-looking secondary label contains essential information, make that information legible. Keep a written label or another cue alongside color when communicating status.
References: W3C: contrast minimum
Read the target-size rule carefully
WCAG 2.2's AA target-size criterion generally uses 24 by 24 CSS pixels, with spacing and other exceptions. A 44 by 44 target can be a useful design preference for frequent touch actions; it is not the AA minimum rule. Review crowded toolbars and inline controls in context rather than applying a single number to every element.
References: W3C: target size minimum
Test forms after something goes wrong
A placeholder is a poor substitute for a persistent field label. Submit an empty or invalid form and inspect how the error is associated with the field. Make sure the explanation helps someone recover and does not erase correct input.
For an illustrative contact form, try an invalid email, a long message and an interrupted submission. Check whether the interface explains what happened and lets the person retry. W3C's forms tutorial provides detailed guidance on labeling, instructions and feedback.
References: W3C: accessible forms
Turn findings into reviewable changes
Report one defect with its location, reproduction steps and intended behavior. For example: 'The icon-only close control has no accessible name; give it a descriptive name and verify it in the accessibility tree.' After the revision, repeat the affected flow.
Keep unresolved issues in the handoff. A generator can propose an improvement, but neither its confidence nor a polished preview is evidence that the requirement has been met.
Accessibility review asks whether people can perceive, understand and operate the actual interface. Measure and test those properties rather than accepting an accessibility claim from the generator.
Sources & further reading
References checked October 18, 2026. Features, prices and account eligibility can change; check the live documentation. Inclusion here is not a hands-on test or vendor endorsement.