# What Automated Accessibility Checks Can and Cannot Find

Traditional Chinese version: [https://accesserty.com/ai/guides/automated-accessibility-checks-limits.md](https://accesserty.com/ai/guides/automated-accessibility-checks-limits.md)

Page version: [https://accesserty.com/en/guides/automated-accessibility-checks-limits/](https://accesserty.com/en/guides/automated-accessibility-checks-limits/)

Last updated: 2026-09-28

Automated checks are useful for missing labels, ARIA errors, some contrast and structure issues, but manual review is still needed for content, flows, keyboard operation, and assistive technology context.

## Summary

- Automated checks are a first filter, not the final conclusion.
- They quickly surface some machine-detectable WCAG and best-practice issues.
- Core task flows, content context, keyboard use, and assistive technology experience still need manual review.

## Use it first to find obvious risks

Automated checks fit well in development, QA, content publishing, and pre-release review. They can quickly identify missing accessible names, ARIA errors, some contrast issues, form labels, and page structure problems.

The result should become a review list, not just a score to optimize.

## Separate findings, review items and untested scope

DevCheck’s axe-core scan separates confirmed findings from items needing manual review. Scope absent from a result cannot be assumed to pass. The following are interpretation examples, not findings from a customer website.

- Finding: button-name identifies an unnamed button. Inspect its purpose, add a meaningful name and scan the same state again.
- Needs review: text contrast may need inspection when its background cannot be determined. Confirm foreground, background and state before deciding; do not assume a pass or failure.
- Untested: an unopened dialog, another page or a complete keyboard task is not evidenced by this scan. Record that scope and arrange a test.
- Zero findings: this run reported no corresponding issues; it does not establish that every success criterion, interaction state or assistive technology passes.

## Then complete the judgment manually

Manual review should cover key tasks: use only the keyboard, confirm focus order, check whether error messages help users continue, and review whether image alternatives fit the context.

Plan assistive-technology testing around the main tasks and include user feedback. A small site should not mark untested announcements or interactions as passed.

## Connect both into one workflow

DevCheck can run machine checks in the current browser tab, then support manual review through review aids, simulations, and AI-assisted suggestions. Pulse brings post-launch interaction barriers back into the team’s view.

- Scan first: find machine-detectable risks.
- Operate next: check keyboard, zoom, simulations, and key task flows.
- Track later: observe reports and repeated interaction barriers after launch.

## Which findings should not be hidden behind a score

Automated tools often summarize results as counts or scores, but release decisions should not rely only on totals. A few issues can be more serious than many low-risk hints, especially when they block a main task, trap keyboard users, or prevent people from knowing how to fix an error.

## Next steps

- [How to check keyboard focus path](<https://accesserty.com/en/guides/how-to-check-keyboard-focus-path/>) — Check whether focus can move, whether the order makes sense, whether focus gets trapped, and whether the path matches the page context.

- [How to implement accessible names](<https://accesserty.com/en/guides/how-to-implement-accessible-names/>) — Check whether buttons, links, form controls, and interactive components expose understandable names.

## Related pages

- [Accesserty DevCheck](<https://accesserty.com/en/devcheck/>) — Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.

- [Accesserty Pulse](<https://accesserty.com/en/pulse/>) — Observe post-launch interaction signals, machine scan summaries, and user reports.

- [Automated vs manual testing glossary page](<https://accesserty.com/en/glossary/automated-vs-manual-accessibility-testing/>)

- [Accessible name implementation guide](<https://accesserty.com/en/guides/how-to-implement-accessible-names/>)

- [Focus path review guide](<https://accesserty.com/en/guides/how-to-check-keyboard-focus-path/>)

- [WCAG testing checklist](<https://accesserty.com/en/guides/wcag-testing-checklist/>)

- [Image alt text guide](<https://accesserty.com/en/guides/writing-meaningful-alt-text/>)

- [PDF accessibility glossary page](<https://accesserty.com/en/glossary/pdf-accessibility/>)

- [W3C WAI: Evaluating Web Accessibility](<https://www.w3.org/WAI/test-evaluate/>) — Explains why tools alone cannot determine accessibility and knowledgeable human evaluation is needed. Consult the tool's documentation for tool-specific result fields.

- [Web accessibility checker](<https://accesserty.com/en/web-accessibility-checker/>) — Check real pages, authenticated states, and interactive states before release.

- [Understand WCAG check results](<https://accesserty.com/en/wcag-compliance-tool/>) — Review WCAG A/AA issue clues, severity, affected elements, and remediation hints.

- [Accessibility practice and maintenance guides](<https://accesserty.com/en/guides/>) — Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.