Real accessibility audit: what human tests reveal and automated tools miss

An automated tool checks observable rules: attribute presence, measurable contrast, heading structure, accessible names, broken ARIA references, unlabeled fields or images without alternatives. This layer is essential because it industrialises alerts and removes obvious mistakes quickly.

Real accessibility also depends on relationships, intent and scenarios. A link can have a name and still be unclear. A button can be detected while opening an interaction that cannot be closed. A form can have labels and still lose leads because errors appear too late, too low on the page or disconnected from the field.

The numbers vary because not everyone counts the same thing: theoretically automatable WCAG criteria, violations found on sample pages, or issue types detected by engines such as axe. The practical decision range is this: automated approaches cover part of the risk, often around one third to slightly over half depending on the method. They never replace human review.

W3C/WAI makes the same distinction: evaluation tools help detect some accessibility issues, but cannot determine accessibility on their own. A reference audit must therefore state what was automated, what was reviewed by humans and what remains outside the scope.

A serious report names the combinations tested: for example NVDA with Firefox or Chrome on Windows, JAWS with Chrome or Edge where relevant, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android for mobile journeys. The choice depends on audience, scope, budget and risk, but it must be explicit.

A useful audit does not flatten everything into one final grade. It separates layers, then connects them. That separation makes corrections actionable: the team can see whether the problem comes from design, content, front-end components, CMS output, ARIA decisions or an unclear business journey.

Put the mouse away and use only the keyboard. You will quickly see whether the interface is mature. Is focus always visible? Does it follow a logical order? Can you open and close the menu? Does hidden content become reachable? Does a modal return focus to its trigger? Does the form announce errors at the right time?

This test is powerful because it crosses code, design, JavaScript, content, components and journeys. It does not replace a full RGAA or WCAG audit, but it exposes blockers that automated scores often miss.

Accessibility does not magically improve rankings or guarantee AI citations. But many audited signals reduce ambiguity: real headings, landmarks, descriptive links, named buttons, connected labels, readable tables, DOM-rendered content and coherent order. In this grid, 5 of the 7 layers also serve machine and agent readability: structure, named interactions, forms, DOM and proof.

That is the bridge with technical SEO and GEO. Before asking a crawler, answer engine or AI agent to understand a page, check that it can be read cleanly. An interface that hides meaning in layout, JavaScript or unnamed components forces systems to guess.

The shift is now visible inside the tooling itself. The Lighthouse 13.3.0 changelog mentions a new agentic browsing category with llms.txt, WebMCP and an agent-accessibility-tree audit. Its label is explicit: a well-formed accessibility tree helps AI agents navigate and interact with the page. This is not a promise of AI citation; it is the clearest signal that agent readability is converging with structure, keyboard access, accessible names and usable content.

After local publication, the page was fixed on a point directly related to the topic: vision cards carried role="listitem" while the parent lost role="list" during HTML normalization. The final rendering now removes the orphan role. That is exactly the kind of detail a tool can reveal, and an article about tool limits cannot afford to ignore.

This page can also show a 100 Lighthouse accessibility score. According to this article’s own thesis, that proves nothing. The score stays a secondary signal: useful proof starts when we look for what Lighthouse does not see and document the corrections.

Pre-publication check performed on July 7, 2026: axe-core 4.12.1 reports 0 automated violations on both French and English versions after fonts are loaded. A complete desktop keyboard pass replayed with Playwright found 54 unique tab stops, returned to the first focus, and found no invisible focus and no focus without a visible outline. During this pass, the page also fixed a badge contrast issue and a scroll-behavior: smooth rule that could delay focus visibility during large jumps.

Explicit limit: this is a pre-publication non-regression proof. It must be rerun on the canonical URL after deployment, with a current toolchain — the current Lighthouse package is 13.4.0 on July 7, 2026 — and completed with an NVDA, JAWS or VoiceOver pass on critical journeys.

For the complete method, this proof does not stand alone: it links back to the Edikka accessibility audit report, published with an RGAA 4.1.2 grid, scope, results, non-conformities and downloadable evidence.

An accessibility audit that ends with “100/100” does not help a team decide. A useful audit answers four questions: what blocks the journey, where, for which user or system, and which correction has the highest impact?

In France, RGAA 4.1.2 provides a method and statement framework. RGAA 5 is announced for late 2026, with WCAG 2.2, mobile apps, office documents and simplified criteria. For products and services covered by the European Accessibility Act, obligations have applied since June 28, 2025. Accessibility therefore affects governance, proof, sales journeys and customer relations, not only front-end implementation.

A published statement without a clear method remains fragile. It should be connected to an audited scope, date, compliance status, non-accessible content, contact channel and remedy path. A real audit gives substance to that statement and makes corrections verifiable.