Accessibility checks to include before a release
A practical starting set for keyboard access, form feedback, readable content, and clear accessibility findings.
Include accessibility checks while a change is still being developed, then repeat the relevant paths on the release build. A useful review follows complete user tasks, including errors, dialogs, and success states.
Begin with a defined scope: the pages, interactions, browsers, assistive technologies, and WCAG level being assessed. This guide offers a starting set of checks. It does not establish full WCAG conformance or legal compliance. W3C’s Easy Checks resource makes the same distinction between a preliminary review and a comprehensive evaluation. W3C WAI: Easy Checks
Choose tasks that expose the interaction
Select a few consequential journeys rather than only scanning the homepage. For a training portal, an example might be finding a course, enrolling, completing an assessment, and returning to a saved lesson.
Include alternate states. A form with valid data may look accessible while its error response leaves a keyboard user without a clear next action. A page can also behave differently after a banner, dialog, or menu appears.
Record the build and test environment before beginning. Keep a separate list of paths you could not assess.
Complete the task with the keyboard
Put the pointer aside and move through the selected journey using the keyboard. Track where focus goes, whether its position is visible, and whether every necessary action can be completed.
Use this working checklist:
- Follow focus from the start of the page through its controls.
- Open menus and dialogs, then close them and continue.
- Check that interaction does not leave focus trapped.
- Trigger validation and locate the information needed to recover.
- Inspect focused controls near sticky headers and banners.
- Complete the task without relying on hover alone.
WCAG 2.2 includes Focus Not Obscured (Minimum), criterion 2.4.11 at Level AA. It addresses a focused component being entirely hidden by author-created content. Record the actual obstruction rather than assuming any overlap is the same failure. WCAG 2.2: Focus Not Obscured
Inspect form names and error recovery
Check whether each input has a meaningful label and whether instructions are available when needed. Trigger errors individually and in combination. The person using the form should be able to identify the problem and take the appropriate next step.
For a fictional registration form, test an empty required field, a value outside the stated rule, and a successful correction. Note whether the error is understandable, whether entered information remains, and whether the user can reach the affected field.
Include a screen-reader pass with an appropriate supported setup when it is within the assessment scope. Record the browser, screen reader, and interaction sequence. Reading the visible text alone does not show how the control is announced.
Check readable content and changing layouts
Increase text size and inspect the same journey again. Look for clipped instructions, controls that disappear, and content that overlaps.
WCAG’s Resize Text criterion addresses enlargement to 200% without losing content or functionality, with stated exceptions. For Level AA text contrast, the minimum is generally 4.5:1, or 3:1 for qualifying large text; consult the criterion for its definitions and exceptions. WCAG 2.2: Resize Text, WCAG 2.2: Contrast
Measure the actual foreground and background combination in the relevant state. Check errors and secondary instructions as well as headings. Record the colors, state, and measurement so the result can be reviewed.
Turn findings into reproducible work
For each issue, state the user task, steps, observed barrier, expected behavior, and relevant criterion. Add an image or recording when it clarifies the interaction. Separate confirmed findings from questions requiring further assessment.
An invented report might say: “After opening the registration dialog and tabbing to Submit, the sticky notice entirely covers the focused button.” Include the environment and exact sequence; do not report only that the page “feels inaccessible.”
Automated checks can contribute evidence, but a clean scan does not answer every manual question. Retest fixes against the original interaction and record remaining scope. The release discussion should reflect both verified results and work still outstanding.