How much of accessibility can be tested automatically?

Missing attributes: an image with no `alt`, a form control with no associated label, an iframe with no title.

Contrast ratios for plain text against a solid background, computed from the rendered colours.

Invalid ARIA: a role that does not exist, an attribute that is not permitted on that role, a reference pointing at an identifier that is absent.

Structural rules: duplicate identifiers, heading levels that skip, a missing `lang` attribute, `aria-hidden` on a focusable element.

These are true failures whenever they are reported. A tool flagging them is not guessing.

Whether alternative text describes the image. `alt="image"` passes the presence check and conveys nothing.

Whether an image marked decorative actually is, which requires knowing what the page is trying to say.

Whether the reading and focus order makes sense, which depends on the meaning of the content rather than on the markup.

Whether a custom widget behaves as its role promises — a `role="tablist"` that does not respond to arrow keys is valid markup and a broken control.

Whether an error message explains anything, whether a label is comprehensible, whether a colour is the only thing distinguishing two states.

A page with no automated findings has cleared the mechanical checks. That is a genuine achievement and it covers roughly a third of the criteria.

The remaining two thirds have not been assessed at all, and nothing in the report says otherwise.

It is entirely possible for a page to pass every automated check and be unusable with a keyboard or a screen reader.

Treating a clean automated report as conformance is the single most common misreading of accessibility tooling.

A keyboard pass. Put the mouse away and complete a real task using Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. This finds a large share of operable failures in minutes and needs no tooling.

Watching the focus indicator throughout that pass, since an invisible one makes the whole interface unusable for sighted keyboard users.

A screen reader pass on the journeys that matter, which is what reveals whether names and roles are correct.

Reading the alternative text out loud in context and asking whether it says what the image contributes.

Testing at a narrow viewport, where a menu becomes a different widget with a different keyboard contract.

VeriFixScan reports the mechanical checks: `accessibility.image_alt`, `accessibility.contrast`, `accessibility.aria_validity`, `accessibility.aria_references`, `accessibility.tabindex` and the landmark and skip-link structure.

It reports what it observed in the served HTML, so a control constructed entirely by scripts is outside what it sees.

It does not operate the page, does not use a keyboard, and does not run a screen reader — which is the boundary of every crawl-based accessibility check, not a limitation of one tool.

The findings it produces are real. The absence of findings is not a conformance claim, and no report should be read as one.