Accessibility Checks: What Probeo Observes

Probeo identifies a subset of WCAG 2.1 accessibility violations through automated structural analysis. This page describes the scope, limitations, and categories of accessibility checks.

Last updated 02/08/2026

Probeo performs automated structural analysis against a subset of WCAG 2.1 criteria. It identifies violations that are deterministic and machine-verifiable: missing alternative text, insufficient color contrast, unnamed interactive elements, absent form labels, and invalid ARIA attributes. Automated checking reliably detects roughly 30% of WCAG issues. The remaining 70% requires manual evaluation, user testing, or contextual judgment that no crawler can replicate.

What Probeo checks

Probeo evaluates page structure against accessibility rules that produce deterministic results. An image either has an alt attribute or it does not. A button either has an accessible name or it does not. These are the kinds of violations automated analysis handles well. Probeo does not attempt to evaluate content quality, reading level, cognitive load, or whether an interaction sequence makes sense to a user with a specific disability. Those require human judgment.

WCAG 2.1 alignment

The checks align with WCAG 2.1 Level A and AA success criteria where the criterion can be evaluated through DOM inspection alone. This includes Success Criterion 1.1.1 (non-text content), 1.3.1 (info and relationships), 1.4.3 (contrast minimum), 4.1.2 (name, role, value), and related criteria. Probeo does not claim WCAG conformance testing. Conformance requires evaluating all 78 success criteria, including those that depend on interaction flow, time-based media, and user context. Automated tools address a fraction of that surface.

Scope and limitations

Automated accessibility testing has well-documented boundaries. Industry research consistently finds that automated tools detect between 25% and 40% of WCAG violations depending on the tool, the site, and how violations are counted. Probeo operates at the structural end of that range: violations that exist in the HTML regardless of user interaction. It does not execute JavaScript interaction sequences, simulate assistive technology behavior, or evaluate content in context. A page that passes all automated checks can still be inaccessible. A page that fails several automated checks may still be usable. Automated results are a starting point for investigation, not a compliance verdict.

Categories of checks

Probeo groups accessibility violations into five areas based on the structural pattern involved. Interactive elements covers buttons and links missing accessible names. Images covers missing or empty alt attributes on informative images. Color contrast covers text and non-text elements falling below WCAG ratio thresholds. Forms covers inputs without associated labels and missing required attributes. ARIA covers missing required attributes on roles and invalid attribute values. Each category has its own documentation page with specific violation patterns, correct markup examples, and verification steps.

What this does not cover

Keyboard navigation, focus management, screen reader announcement order, dynamic content updates, motion preferences, and content readability are all outside the scope of automated structural analysis. These require testing with real assistive technology and real users. Probeo makes the machine-detectable violations visible so teams can fix the obvious issues first and allocate manual testing effort where it matters.

What becomes visible

Structural accessibility violations that exist in the HTML at crawl time
Which pages have missing alternative text, unnamed controls, or insufficient contrast
Where ARIA usage deviates from the WAI-ARIA specification
Which form inputs lack programmatic association with their labels
The boundary between what automated checking covers and what it cannot

Common questions

Does passing Probeo's accessibility checks mean a site is WCAG compliant?

No. WCAG conformance requires evaluating all applicable success criteria, including many that automated tools cannot test. Probeo covers a subset of machine-verifiable criteria. Passing automated checks is necessary but not sufficient for conformance.

Why does Probeo not test keyboard navigation or screen reader behavior?

Keyboard and screen reader testing require simulating interaction sequences and evaluating subjective outcomes. Probeo performs static structural analysis of HTML. These are different testing methodologies with different strengths.

How does Probeo relate to tools like axe-core or WAVE?

Probeo operates at crawl time across all pages rather than on a single page at a time. It identifies many of the same structural violations but in the context of site-wide observability rather than developer-time auditing.

Should automated checks be run before or after manual accessibility testing?

Before. Automated checks surface the deterministic violations quickly. Fixing those first means manual testing effort focuses on the issues that require human judgment rather than catching missing alt attributes.

Can a page fail automated checks and still be accessible?

In some cases, yes. For example, a decorative image flagged for a missing alt attribute may be correctly omitted from the accessibility tree through other means. Automated results require interpretation.

Does Probeo test accessibility in single-page applications?

Probeo evaluates the HTML rendered at crawl time. For SPAs that render content client-side after JavaScript execution, the checks apply to whatever DOM state the crawler observes. Dynamic state changes triggered by user interaction are not evaluated.