An automated accessibility scan can find a missing form label. It cannot tell you whether the form makes sense after the third validation error moves focus somewhere unexpected.
That is not a criticism of automated testing. I want it in development and CI because machines are excellent at checking deterministic rules across hundreds of pages. The mistake is treating a clean report as proof that a person can complete the task.
W3C is blunt about this: evaluation tools cannot determine whether a site is accessible. Human judgment is required.
These are the eight manual checks I run on a representative route and the product’s most important flow.
1. Complete the task with a keyboard
Put the mouse aside. Reload the page and finish a real task using Tab, Shift+Tab, Enter, Space, arrow keys, and Escape.
Do not merely tab from the logo to the footer. Try the thing the page exists to support:
- Open the mobile or desktop navigation.
- Fill and submit a form.
- Change a filter or sort order.
- Open and close a dialog.
- Complete checkout or account recovery.
Every control must be reachable, operable, and escapable. A custom dropdown that receives focus but ignores arrow keys is not keyboard support. A dialog that can be opened but not closed without a pointer is a trap.
Watch the order. Focus should follow the visual and logical task, not jump into an off-screen drawer or footer link because of DOM placement.
2. Follow the focus indicator
Start the keyboard test again, this time watching only focus.
You should always be able to answer “where am I?” The indicator needs enough contrast against the component and its surroundings. A one-pixel gray outline that disappears on a dark button technically exists and practically does not.
Pay special attention when the interface changes:
- Opening a dialog should move focus into it.
- Closing it should return focus to the control that opened it.
- Adding an error summary should move or announce focus deliberately.
- Removing the focused element should place focus somewhere sensible.
- Client-side navigation should not leave focus stranded in the old route.
Mouse clicks can hide all of these problems because the pointer supplies location context that a keyboard user does not have.
3. Zoom until the layout becomes inconvenient
Test the page at 200 percent browser zoom, then at a narrow viewport or higher zoom that forces reflow.
Look for:
- Text clipped by fixed-height containers
- Horizontal scrolling needed to read ordinary paragraphs
- Controls covered by sticky headers or cookie banners
- Two-column forms whose labels separate from inputs
- Dialog content that cannot be reached or scrolled
- Buttons reduced to unexplained icons
Do not “solve” overflow by preventing zoom. Users zoom because they need the content larger.
Also increase the operating system’s text size when the product supports platforms where that setting affects the browser. Browser zoom and text scaling expose different assumptions.
4. Listen to names, roles, and state
Turn on VoiceOver, NVDA, Narrator, or another screen reader you can test competently. Navigate by headings and controls before reading every line.
Listen for what the interface calls things:
- Does “Search” identify the site search, or are there three controls named “button”?
- Does an icon-only control announce its action rather than the icon’s filename?
- Does a toggle announce whether it is on or off?
- Does an expanded menu announce that state?
- Do heading names describe the sections that follow?
The accessible name should match the visible language closely. A visible “Save draft” button announced as “Submit form” forces users to translate between two interfaces.
One short screen-reader session catches surprising failures, but it does not make one tester a substitute for disabled users. Include people who use assistive technology in research and acceptance testing when the product and risk justify it.
5. Submit every form incorrectly
Leave required fields empty. Enter an invalid email. Use a value at the minimum and maximum length. Trigger a server error if a safe test environment allows it.
Check that:
- Required fields are identified before submission.
- Errors are associated with the relevant controls.
- An error summary links or moves focus to the problem.
- Existing valid values remain intact.
- Instructions do not rely on color alone.
- The message explains how to recover.
Then fix one field and submit again. Some forms announce the first error correctly and go silent on the second attempt.
W3C’s Easy Checks include practical starting points for labels, errors, headings, contrast, keyboard access, and focus.
6. Stress menus, dialogs, and live updates
Static HTML is the easy part. Test the components that appear, disappear, reorder, or update without a full page load.
For a dialog:
- Focus enters at a useful place.
- Background content is not accidentally interactive.
- Escape closes it when appropriate.
- The close control has a clear name.
- Focus returns on close.
For a menu or combobox, verify the expected arrow-key behavior, current selection, Escape behavior, and typing support where applicable.
For live updates, ask whether the change is announced at the right urgency. A background save confirmation should not interrupt every sentence. A payment failure cannot be a silent red border.
Use native elements before building a custom interaction model. Native controls bring years of browser and assistive-technology behavior that a styled div does not inherit.
7. Remove motion and wait out time limits
Enable the operating system’s reduced-motion preference and reload. Decorative movement should stop or become meaningfully quieter. Essential progress should remain understandable.
Test carousels, video, animated backgrounds, smooth-scrolling navigation, and route transitions. Give moving content a pause control when required. Make sure disabling animation does not also hide content that was supposed to animate into view.
If a session, quiz, reservation, or checkout expires, test the warning and extension path. The user needs enough time to perceive the warning, reach it, and act. A timer visible only as changing color is not enough.
Also check loading states. A skeleton that pulses forever after an error can be both a motion problem and a missing failure state.
8. Read the page without its visual design
Turn off CSS, use a reader view, or navigate by headings and landmarks. Then read the alternative text for meaningful images.
Ask:
- Does the heading outline describe the actual page?
- Are instructions meaningful without position or color, such as “use the green button on the right”?
- Does link text make sense out of context?
- Is alternative text serving the image’s purpose rather than listing objects?
- Are decorative images silent?
- Do tables keep meaningful headers and captions?
This is the content test automated tools cannot finish. A tool can confirm that alt exists. It cannot know whether “dashboard screenshot” communicates the chart’s conclusion or whether the image is redundant beside the paragraph.
Choose representative pages
You do not need to repeat every manual test on every URL for every commit. Choose a set that covers the system:
- Homepage or primary landing page
- Navigation at desktop and mobile widths
- Most complex form
- Authentication flow
- Data-heavy page
- Dialog or overlay workflow
- Error and empty states
- One article or long content page
Run automated checks broadly, then use these pages for manual release testing. Add a page when it introduces a new interaction pattern.
SiteCMD’s accessibility checks combine static markup signals with optional axe-core analysis of the rendered page. They intentionally stop short of claiming full conformance. The manual checks above cover the behavior and meaning a scanner cannot decide.
The pre-launch website checklist places this accessibility pass beside the build, critical flows, security, performance, privacy, monitoring, and rollback work needed for a real release.
The scan checks rules at scale. The manual pass proves someone can finish the job.