Testing & Scanners

The Honest Manual-Review Checklist (What Automated Scans Cannot Find)

Last updated May 24, 2026

Per Deque's Automated Accessibility Coverage Report, Deque reported automated tests identified 57.38% of issue instances by volume in its dataset — based on 2,000+ audits across 13,000+ pages and ~300K issues. That is a share of issue *volume*, not a share of WCAG criteria automation can fully verify, and it is the most generous published number from the engine vendor itself. Per WebAIM Million 2025, the average home page had 50.96 detectable errors. Automated detection caught only a fraction of the WCAG issues that human testers identify on the same pages. The rest needs a human, a keyboard, and a screen reader.

This page is the practical complement to what scanners miss, which explains the theory of where automation has gaps. Here you get the checklist. Thirty concrete items grouped into seven sections, each with the test, the test method, the relevant WCAG success criterion, and one line on why a scanner cannot decide it for you. The screen-reader scripts name the assistive technology explicitly — NVDA on Windows, VoiceOver on macOS and iOS, JAWS on Windows, and TalkBack on Android — because the right answer depends on which AT a real user happens to be running.

SweepHound's stance is simple. Run a dual-engine automated scan to nail the deterministic floor, then walk through this checklist on your highest-traffic flows. The combination is what the W3C's preliminary-review methodology recommends, and what Deque's own program guidance calls out: accessibility programs benefit from both manual and automated testing, not one in place of the other. A checklist will not make your site WCAG conformant on its own. It will make the manual review finite, repeatable, and honest.

How to use this checklist

Pick your top five pages. For most teams that means the home page, the top landing page from organic search or paid ads, the key conversion page (signup, demo request, add-to-cart), the account/login flow, and the checkout or equivalent transactional page. These five pages drive the majority of real user impact, and they are also the pages most likely to be legally scrutinized in an ADA or EAA complaint.

For each page, work through all 30 items. Time-budget around 45–60 minutes per page for a first pass; experienced reviewers get faster. Document findings as you go — a shared spreadsheet with columns for page, item, AT used, severity, and remediation owner works fine. Re-test after fixes, ideally with the same AT/browser combination you found the issue with, because the same DOM can sound clear on one screen reader and broken on another.

Do an automated scan first via our testing overview so the deterministic issues are already triaged. Then this checklist focuses your manual time on what scanners cannot reach.

Section 1 — Keyboard navigation (6 items)

Unplug your mouse or trackpad. Use only Tab, Shift+Tab, Enter, Space, Esc, and the arrow keys. If at any point you cannot reach, operate, or escape something, that is a finding.

1. Reach every interactive element. Tab through the page from the top. Confirm you can land on every link, button, input, select, checkbox, radio, custom widget, and third-party embed. Keyboard only. WCAG SC 2.1.1 Keyboard. Scanners check tabindex presence; they do not actually press Tab and see whether a custom widget is reachable.
2. Tab order matches visual order. As you Tab, confirm focus moves left-to-right and top-to-bottom in the same sequence a sighted user would read. Watch for jumps to hidden menus, off-screen sidebars, or third-party iframes that grab focus. WCAG SC 2.4.3 Focus Order. Scanners cannot evaluate DOM-vs-visual order under CSS Grid, Flexbox order, or responsive reflow.
3. Shift+Tab reverses correctly. From the bottom of the page, Shift+Tab back to the top. Focus should visit the same elements in reverse, without skipping or getting stuck. Keyboard only. WCAG SC 2.4.3 Focus Order. Scripted focus traps and managed focus often break reverse traversal even when forward Tab is clean.
4. Escape every component. Open each modal, mega-menu, dropdown, popover, and date picker. Confirm you can dismiss it with Esc, or that there is a clearly focusable close affordance reachable without a mouse. WCAG SC 2.1.2 No Keyboard Trap. Scanners cannot determine whether Esc is wired up or whether the close button is keyboard-reachable in practice.
5. Focus indicators are visible. On every focusable element, the focus ring or outline must be clearly visible against the content behind it. Custom buttons, cards, dropdowns, and links inside dark hero sections are the usual offenders. WCAG SC 2.4.7 Focus Visible and SC 2.4.11 Focus Not Obscured (Minimum, WCAG 2.2). Scanners check outline: none but cannot evaluate whether the replacement indicator has enough contrast or is occluded by a sticky header.
6. Skip links work.Press Tab once from a cold page load. The first focusable item should be a visible “Skip to main content” link (or equivalent). Activate it; focus must land on the main content area, not return to the top of the page. WCAG SC 2.4.1 Bypass Blocks. Scanners can detect skip-link presence but cannot confirm it transfers focus correctly when activated.

Section 2 — Screen reader experience (6 items)

Choose one of these combinations: NVDA + Firefox on Windows, VoiceOver + Safari on macOS, VoiceOver + Safari on iOS, or TalkBack + Chrome on Android. JAWS + Chrome on Windows is the enterprise standard if your audience skews that way. For a thorough review use at least two AT/browser combos — the same DOM frequently sounds right on one and garbled on another. See our screen-reader guide for setup; the WebAIM screen-reader testing methodology is the canonical longer reference.

1. Reading order matches visual order. On NVDA press Insert+Down to read all, on VoiceOver press VO+A, on JAWS press Insert+Down Arrow, on TalkBack use the read- from-top gesture. Confirm content is announced in the order a sighted user would read it. WCAG SC 1.3.2 Meaningful Sequence. Scanners cannot evaluate this for layouts using Flex/Grid reordering or absolutely positioned content.
2. Image alt text is meaningful. On NVDA press G to jump between graphics, on VoiceOver use the rotor (VO+U) to list images, on JAWS press G, on TalkBack use the Images reading control. Listen to each announcement; reject “image,” filenames, and duplicate alt text that repeats the adjacent caption. WCAG SC 1.1.1 Non-text Content. Scanners cannot judge whether alt text is meaningful — only that it exists.
3. Heading hierarchy is logical. On NVDA press H to navigate by heading and Insert+F7 for the element list, on VoiceOver use VO+Cmd+H to step through headings (and VO+U for the rotor heading list), on JAWS press Insert+F6 to list headings, on TalkBack use the Headings reading control. The outline should tell the story of the page. WCAG SC 2.4.6 Headings and Labels and SC 1.3.1 Info and Relationships. Scanners validate rank order but cannot tell whether the outline makes sense.
4. Landmarks announce correctly. On NVDA press D to navigate by landmark, on VoiceOver use the rotor (VO+U) and choose Landmarks, on JAWS press R, on TalkBack use the Landmarks reading control. Confirm banner, navigation, main, contentinfo, and aside are present and labeled distinctly when there are multiples. WCAG SC 1.3.1 Info and Relationships and SC 2.4.1 Bypass Blocks. Scanners confirm landmarks exist; they do not check whether multiple identical labels confuse real navigation.
5. Form labels announce and describe. Tab into each input. Confirm the screen reader announces the visible label, the input type, any required state, and any help text via aria-describedby. WCAG SC 3.3.2 Labels or Instructions and SC 1.3.1. Scanners verify the for/id association but cannot evaluate whether the label and described text together actually make sense when announced.
6. Dynamic updates announce. Trigger a toast, a validation error, a cart count change, and a search-results update. Confirm each is announced — politely for informational updates (role="status" or aria-live="polite") and assertively for errors (role="alert"). WCAG SC 4.1.3 Status Messages. Scanners detect live-region attributes but cannot confirm they fire on the right event or at the right politeness.

Section 3 — Focus management (4 items)

Focus tells keyboard and screen-reader users where they are. When focus is mishandled, the experience falls apart even if every other check passes.

1. Modal focus moves in and restores out. Open every modal via keyboard. Focus should immediately move inside the dialog (typically to the first interactive element or the heading). On close, focus should return to the trigger that opened it. Test with NVDA or VoiceOver to confirm the dialog is also announced. WCAG SC 2.4.3 Focus Order and TPGi ARIA pattern guidance for dialogs. Scanners cannot test event-driven focus transitions.
2. Focus visible at all times during nav. Tab around. The focus ring must remain visible — never hidden by a sticky header, off-screen, or rendered behind a modal backdrop. Keyboard only. WCAG SC 2.4.7 Focus Visible and SC 2.4.11 Focus Not Obscured. Scanners cannot evaluate layered z-index occlusion or sticky-header overlap.
3. Async actions move focus. Submit a form with errors, then with success. After an error, focus should move to the first invalid field or an error summary. After success, focus should move to the success message or the next logical step. Test with NVDA or VoiceOver. WCAG SC 3.3.1 Error Identification and SC 4.1.3 Status Messages. Scanners cannot evaluate runtime focus changes after async events.
4. Hidden elements do not receive focus. Tab through the page with menus and modals closed. Confirm focus does not enter elements that are visually hidden via display: none, visibility: hidden, or off-screen positioning while still being focusable. WCAG SC 2.4.3 Focus Order. Scanners flag some cases but routinely miss CSS-driven hidden focusables under transforms or clip-paths.

Section 4 — Forms and errors (5 items)

Forms are where accessibility failures cost real money — abandoned checkouts, blocked signups, support tickets. Test every form on your top five pages.

1. Required indicators visible and announced. For each required field, confirm there is a visible required indicator (an asterisk, the word “required,” or equivalent) AND the screen reader announces “required” when the input is focused. Test with NVDA, VoiceOver, or JAWS. WCAG SC 3.3.2 Labels or Instructions and SC 1.3.1. Scanners detect the required attribute but cannot verify the visual cue exists.
2. Error messages associate with fields. Submit each form with bad input. Confirm each error message is associated with its input via aria-describedby (or aria-errormessage) and announced when the field gains focus. NVDA, VoiceOver, or JAWS. WCAG SC 3.3.1 Error Identification and SC 3.3.3 Error Suggestion. Scanners detect the attribute but cannot confirm the content makes sense in context.
3. Error summary on submit. On a multi-field form, submit with multiple errors. There should be a visible error summary at the top, focus should move to it (or to the first invalid field), and a live region should announce the failure count. Test with NVDA or VoiceOver. WCAG SC 3.3.1 and SC 4.1.3 Status Messages. Scanners cannot evaluate multi-error UX patterns.
4. Autocomplete attributes present. Inspect every input that takes personal data — name, email, phone, address, payment fields. Confirm appropriate autocomplete values are set (email, tel, given-name, etc.). WCAG SC 1.3.5 Identify Input Purpose. Scanners detect missing attributes but cannot judge whether the value is correct for the field's actual purpose.
5. Password fields support paste and managers. Try pasting into every password field. Try a password manager (1Password, Bitwarden, browser-native). Both must work. WCAG SC 3.3.8 Accessible Authentication (WCAG 2.2). Scanners cannot test for paste-blocking event handlers or hostile autofill suppression.

Section 5 — Content and meaning (5 items)

The slice of accessibility that scanners are structurally unable to touch: whether the words on the page actually convey the meaning they need to.

1. Page title describes the page. Read the browser tab title for each page. It should uniquely describe the page and the site (e.g. “Pricing — Acme” not “Acme” on every route). Screen readers announce the title on page load. WCAG SC 2.4.2 Page Titled. Scanners detect title presence and uniqueness across a crawl but cannot judge descriptiveness.
2. Link text meaningful out of context. Use NVDA Insert+F7 or VoiceOver VO+U > Links to list every link on the page in isolation. Each link text should make sense without surrounding sentence context. Replace “Read more” with “Read more about pricing,” and “Click here” with the destination. WCAG SC 2.4.4 Link Purpose (In Context) and SC 2.4.9 Link Purpose (Link Only). Scanners cannot judge meaning.
3. Headings describe their section. Read each heading aloud. Does it describe what follows, or is it just a visual style applied to body text? “Why us” is weaker than “Why teams choose SweepHound.” WCAG SC 2.4.6 Headings and Labels. Scanners cannot evaluate content quality.
4. Alt text is purposeful. For each meaningful image, confirm the alt text describes the information the image conveys, not its appearance. For decorative images, confirm alt="" is intentional. See our alt-text guide for the decision tree. WCAG SC 1.1.1 Non-text Content. Scanners verify presence; the meaning call is human.
5. Color is never the only signal. Inspect every chart, status badge, required-field marker, and error state. Confirm meaning is also conveyed via text, icon, shape, or pattern — not color alone. WCAG SC 1.4.1 Use of Color. Scanners cannot infer semantic intent from styling.

Section 6 — Visual and media (4 items)

Some of these have automated checks, but the rendered-pixel reality frequently diverges from what the scanner sees in CSS.

1. Color contrast at rendered size. Use a contrast checker (browser devtools or the WebAIM contrast checker) on text at its actually-rendered color and background — including text over gradients, video, or images. Body text must meet 4.5:1; large text and UI components 3:1. WCAG SC 1.4.3 Contrast (Minimum) and SC 1.4.11 Non-text Contrast. Scanners handle solid backgrounds well; gradients, overlays, and mix-blend-mode require a manual pixel-level check.
2. Focus indicator contrast. For each focusable element, confirm the focus ring has at least 3:1 contrast against adjacent colors. Pay special attention to elements on brand-colored backgrounds and dark heroes. WCAG SC 2.4.11 Focus Appearance and the 2.4.13 focus appearance criteria. Scanners check outline presence; layout-aware contrast against the adjacent pixel requires a human eye.
3. Animation respects reduced motion. Enable the OS reduced-motion preference (System Settings on macOS, Settings > Accessibility on Windows, iOS, and Android). Reload the page. Confirm parallax, autoplay carousels, decorative motion, and large hero animations are reduced or removed. WCAG SC 2.3.3 Animation from Interactions. Scanners cannot detect runtime motion that respects or ignores the media query.
4. Video has captions and audio description. For every video, confirm captions are present, accurate, and synchronized — not auto-generated nonsense. For videos conveying information visually that is not in the audio track, confirm audio description or an accessible alternative is provided. WCAG SC 1.2.2 Captions (Prerecorded) and SC 1.2.5 Audio Description (Prerecorded). Scanners detect a <track> element; they cannot evaluate caption quality.

Quick screen-reader command reference

The minimum keystrokes you need to run the Section 2 checks. Cross- reference the WebAIM screen-reader testing reference for the full command list.

NVDA (Windows)

• Insert+Down Arrow — read continuously from cursor
• H — next heading; 1–6 — by level
• D — next landmark; R — next region
• G — next graphic; K — next link; F — next form field
• T — next table; Insert+F7 — element list

VoiceOver (macOS)

• Cmd+F5 — toggle VoiceOver on/off
• VO+A — read all from current location
• VO+Cmd+H — next heading; Shift to reverse
• VO+U — open the rotor for headings, links, landmarks, form controls
• VO+Right/Left Arrow — navigate by item

VoiceOver (iOS)

• Enable: Settings > Accessibility > VoiceOver, or triple- click the side button when shortcut is configured
• Swipe right/left — next/previous item; double-tap — activate
• Two-finger swipe up — read from top; rotor (rotate two fingers) — navigate by heading, landmark, link

JAWS (Windows)

• Insert+Down Arrow — say all
• Insert+F5 — list form fields; Insert+F6 — list headings; Insert+F7 — list links
• H — next heading; R — next region; G — next graphic

TalkBack (Android)

• Enable: Settings > Accessibility > TalkBack
• Swipe right/left — next/previous item; double-tap — activate
• Swipe up-then-right — open reading controls (Headings, Landmarks, Links)
• Swipe down-then-right — toggle reading controls forward/back

How SweepHound supports manual-review work

We do not pretend a scanner can replace this checklist. We do try to make the manual work as short as possible. After every scan, SweepHound generates a per-site manual-review checklist that is narrower than this canonical 30-item list: it includes only the items relevant to what the scan actually found, plus the items known to be unscannable for the page types we crawled.

Concretely, if your scan flagged 0 dynamic-update issues but found 15 link-text edge cases, your generated checklist prioritizes Section 5 over Section 2. If your scan covered a checkout flow, it adds the Section 4 form items in front. We pull from the same underlying success criteria as this page; the difference is ordering and emphasis. The general guidance — that programs benefit from both manual and automated testing — comes straight from Deque's program guidance.

If you want to see your own site's narrowed checklist alongside a dual-engine scan, start a free scan. The free tier gives you the full crawl, grouped findings, and a guided manual checklist. Paid tiers add authenticated scanning for logged-in flows, scheduled re-scans, and the public statement generator; see pricing for details. Or jump straight to sign up and run your first scan in under a minute.

Related reading: keyboard navigation deep-dive, screen-reader testing, and keyboard traps.