Website · THE NO-PANIC PLAN
Run a manual accessibility check before a website launch
An accessibility checklist helps a team find common barriers before launch, but it is not a conformance certificate. This workflow selects representative page types, creates a focused review checklist, and guides a human through keyboard-only use, visible focus, headings and alternatives, form labels and errors, text contrast, zoom/reflow, and a final issue record. Nirmion's Accessibility Test Checklist creates a browser-local checklist; it does not inspect the website or automatically detect failures. Use WCAG 2.2 as the reference, involve disabled users and assistive technologies in a fuller evaluation, and send unresolved barriers to the responsible owner before release.
MISSION Review a representative website page for common accessibility barriers using keyboard, zoom, content, form, and contrast checks before launch.
Create a focused manual accessibility test checklistTHE REAL-WORLD BIT
What happens outside this browser tab?
Select representative templates and user journeys; generate a bounded checklist; test keyboard access and focus; inspect headings, links and meaningful text alternatives; complete forms and verify labels and errors; check text contrast and zoom/reflow; then record reproducible findings, prioritize blockers, retest fixes, and document the limits of this manual review.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Choose representative pages and define the review scope
List the page templates and key journeys that users must complete, such as landing pages, search/results, sign-in, checkout, support, and forms. Select representative pages, including dynamic states, error messages, dialogs, and mobile layouts. Record the browser, viewport, build, and test account used so another reviewer can reproduce the check. Use Nirmion's Accessibility Test Checklist to create a browser-local task list for the agreed scope. The tool prepares a checklist but does not visit the site, run an audit, or determine WCAG conformance. (Sources 1, 2, 3)
- 02
Complete the main journey with a keyboard only
Unplug or avoid the mouse and move through the page using Tab, Shift+Tab, Enter, Space, and arrow keys where the component expects them. Confirm that interactive controls receive a visible focus indicator, focus follows a sensible order, and no control traps the user. Open and close menus, dialogs, accordions, and media controls; check that focus enters and returns from overlays as expected. For custom widgets, compare the behavior with the relevant WAI-ARIA Authoring Practices pattern. Record the exact control and action when navigation fails. (Sources 1, 2, 4)
- 03
Review headings, links, images, and page meaning
Read the page structure without relying on visual styling: headings should communicate the content hierarchy, link text should make sense in context, and repeated navigation should be understandable. For meaningful images, check that the text alternative conveys the image's purpose; decorative images should not add distracting redundant text. Check that instructions and status messages are available as text and are not conveyed only by color, position, or shape. Automated checks can flag some missing attributes, but a person must judge whether the text gives an equivalent purpose and whether the page's structure is clear. (Sources 1, 2, 3)
- 04
Complete forms and inspect labels, instructions, and errors
Use each representative form with keyboard navigation. Confirm every input has a programmatically associated label, required fields and formats are explained before submission, and errors identify the affected field in text with a useful correction suggestion. Check that error messages are not conveyed only through red outlines and that entered values are not lost after a validation failure. Verify that grouped choices have a clear group label and that confirmation or progress updates are perceivable. W3C's forms guidance explains common label and instruction techniques; test the actual rendered form rather than relying only on source-code presence. (Sources 1, 2, 5)
- 05
Check text contrast and do not use color alone
Measure text against its actual background in normal, hover, focus, disabled, and error states. For WCAG 2.2 Level AA, normal text generally needs a contrast ratio of at least 4.5:1 and large text at least 3:1, with defined exceptions. Check that links, status, required fields, and charts are not distinguishable only by color. Record the foreground/background colors and the text size for each failure. A contrast tool can calculate a ratio but cannot decide whether the page communicates meaning or meets every accessibility requirement. (Sources 1, 2, 6)
- 06
Test zoom, reflow, and responsive interaction
Increase browser zoom and inspect narrow viewport behavior for clipped text, overlapping controls, lost content, and unexpected two-direction scrolling. Check that text remains readable and interactive controls remain usable without requiring precise pointer movements. Repeat important tasks at the layouts users are likely to use and verify that mobile menus, sticky elements, and dialogs do not obscure focus or instructions. Note the exact browser, zoom level, viewport, and page state. This manual check is a useful screen, not a complete measurement of WCAG reflow or every assistive-technology combination. (Sources 1, 2, 3)
- 07
Log issues, assign fixes, and retest the changed pages
For each barrier, save the page and state, reproduction steps, expected behavior, actual behavior, user impact, browser and assistive technology if applicable, and a privacy-safe screenshot or recording. Assign an owner and severity using the site's release process; fix blockers in the affected templates and rerun the same steps after changes. Keep both the original finding and retest result so regressions can be detected. A manual checklist samples selected pages and cannot establish legal compliance or full WCAG conformance. For a formal evaluation, combine multiple methods and include people with disabilities in representative tasks. (Sources 1, 2, 3)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10
- W3C Recommendation: Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI: Easy Checks - A First Review of Web Accessibility
- W3C WAI: Selecting Web Accessibility Evaluation Tools
- WAI-ARIA Authoring Practices: Keyboard Interface
- W3C WAI Forms Tutorial: Labels
- Understanding WCAG 2.2: Contrast Minimum