Skip to main content :::
:::

What Automated Accessibility Checks Can and Cannot Find

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.

Last updated:

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 checks in this workflow

Choose a follow-up task that applies to your page. PDF checks are needed only when documents are part of the task; a fix still needs retesting.

  1. Review keyboard and focus path

    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.

  2. Review accessible names

    How to implement accessible names

    Check whether buttons, links, form controls, and interactive components expose understandable names.

Related pages