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.

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.

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.

For products used by many people, assistive technology testing and real user feedback should also be part of the process.

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

This guide is part of the DevCheck pre-release checking path. After this check, continue with the next tasks below.

  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