What a 94% Accessibility Score Actually Proves
Someone ran this site through a free third-party compliance scanner. It came back with 94%, a green badge reading Compliant, and twenty findings. We checked every one of them against the actual pages. Two were real — and both had gone straight past our own test harness.
The number is the least useful part
WCAG does not have percentages. Conformance is defined success criterion by success criterion, and a page either satisfies one or it does not. There is no arithmetic that turns "satisfies 47 of 50 criteria" into a grade, because the three it misses might be the three that stop somebody using the site at all.
So a scanner reporting 94% is reporting something about its own checklist, not about your obligations. Ours came with a badge saying the site "meets WCAG 2.1 AA compliance standards" and "maintains ongoing legal accessibility compliance." No automated tool can establish either of those things, and we would say the same about a report that gave us 100%.
A score is a summary of what one tool checked. It is not a finding, and it is certainly not a legal position.
None of which makes the findings worthless. It makes them findings — things to go and verify, one at a time, against the page they name. That is what we did.
The scoreboard
Twenty findings, all from a scan of a single page. Grouped by what they claimed, with what we found when we checked:
| What it reported | Count | What we found |
|---|---|---|
| Low text contrast, marked critical | 1 | Could not reproduce. It named no element, no selector and no page position. |
| Heading and reading-sequence problems | 7 | None reproduced. Three were provably wrong; two were the scanner's own text extraction cutting our sentences short. |
| DOM order does not match visual order | 2 | Accurate as a measurement. It is describing a two-column layout. |
| One destination reached under several link texts | 5 | Four are deliberate wording. One was pointing at a real problem without saying so. |
| A card announced as a single block | 2 | Real. Our mistake, and a good catch. |
| Form with no accessible name | 1 | Real. Two of them, in fact. |
| Focus obscured by the sticky header | 1 | Could not reproduce across 177 tab stops on four pages. |
| Only one way to locate content | 1 | Arguable. Navigation, footer and breadcrumbs are three, but no site search. |
Why the misses missed
Worth going through, because the failure modes are instructive rather than embarrassing for anyone.
The critical one had no address
The single critical finding was a contrast failure attributed to Chrome's issue reporting. So we asked Chrome. Running its own issues panel across the full page returned zero issues of any kind, contrast included. Our axe-core runs report zero contrast violations and — more importantly — zero results axe could not decide, across 46 captures.
A finding with no element attached cannot be fixed or refuted. It can only be believed.
The heading claims were checkable, and wrong
Three findings said headings were nested wrongly: an H4 with no H3 parent, an H3 "orphaned" from any H2, an H3 with no content beneath it. Extracting the full heading outline gives zero level skips. The H4s sit under an H3 that sits under an H2. The "orphaned" H3 is a direct child of the H2 immediately above it. The H3 with no content is followed by a table — which the scanner did not read.
Two findings were the tool describing itself
"Truncated text content" and "content appears cut off mid-sentence in multiple places." You can see this happening in the report itself, where our copy is quoted as Recipients of HHS federal financia and Cities, counties, schools, unive. The extractor truncates around sixty characters, and the truncation is then filed as a defect in our markup. To its credit the report hedged — "either extraction error or actual DOM issue."
Two-column layouts are not a defect
"DOM order does not match visual order" is true here. A two-column section puts the right column's heading visually above the lower half of the left column, while the DOM has left column then right column. That is how multi-column layouts work. 1.3.2 Meaningful Sequence applies where sequence carries meaning; two independent columns do not have a meaning-carrying order between them.
"May be obscured" is not a measurement
Eight focusable elements were reported as possibly hidden behind the sticky header when
focused — a genuine WCAG 2.2 criterion, 2.4.11 Focus Not Obscured, and
one automation is bad at. So we measured it: tab through every focusable element on
four pages, comparing each focused element's box against the header's. 177 tab stops,
zero overlaps. The stylesheet has carried scroll-padding-top since before
the scan.
Note the hedge in the wording. "May be" is what a static guess sounds like.
What it got right
This is the part that mattered, and the reason the whole exercise was worth a morning.
Our cards announced as one long link
Several pages use a card that is entirely clickable — the whole rectangle is one
<a>, containing a heading, a paragraph and a "read more" line. Good for
pointer and touch targets. What it also does is make the link's accessible name the
concatenation of everything inside it.
Two of ours computed to 182 and 171 characters. A screen-reader user pulling up a list of links on that page heard this:
"State and local government Cities, counties, schools, universities, libraries, courts, election offices, transit, parks, utilities and special districts. ADA Title II and WordPress, link."
Nothing flagged it. WCAG 2.4.4 Link Purpose is satisfied — over-satisfied. axe passes it,
because "does this control have a name" is automatable and "is that name any good" is
not. The fix was aria-labelledby pointing at the card's own heading, so the
name is the heading alone and the whole card stays clickable. Seventeen links, now 9 to
26 characters each.
The scanner reported this twice, under two different headings — once as "three visual blocks announced as one," and once, unrecognisably, inside a finding about link wording. Only one of those framings made the problem obvious.
Two forms with no accessible name
Our compliance-date finder and our review request form both lacked one. This is not a
violation, which is exactly why no automated check raises it — but a
<form> is only exposed as a form landmark once it has an accessible
name. Without one it is not a landmark at all: it cannot be jumped to, and it announces
nothing about its purpose. Both now carry an aria-label.
There is a nice trap buried in this one. If you go looking for unnamed forms in the accessibility tree, you will find none — ever. The name is what promotes the element to a landmark, so an unnamed form does not appear in the tree with that role at all. You have to ask the DOM.
We fixed the site, then fixed the harness
Correcting two defects is the small half. The larger question is why our own testing reported a clean result on both — 46 captures, zero violations, zero undecidable results — while both were sitting there.
The answer is that we were testing name presence and never name quality. So we added a pass to the harness we point at client sites. It reads the computed accessible name of every link and button on the page and reports:
- Names longer than 100 characters, which usually means a whole card inside one link
- Uninformative names, the "click here" and "read more" family
- One name pointing at several different destinations
- A form with two or more controls and no accessible name, asked of the DOM rather than the tree
- One destination reached under several names, reported as information rather than as a fault
It never gates a build. "Too long" and "too generic" are judgement calls, and a threshold that suits this site would be wrong for another one. It goes in the same section of the report as our keyboard traversal: read this, decide for yourself.
We tested it the only way worth testing a new check — by pointing it at the version of the site that still had the defects, and confirming it found both without being told where to look. Then at the fixed version, to confirm it went quiet.
The uncomfortable version
It would be a tidier story if the scan had been worthless. It was not. A tool that we could not reproduce on fourteen of twenty findings still handed us two real defects that we had missed while actively looking for defects, on our own site, which we care about more than is reasonable.
Both were in the same place: the gap between what a rule can express and what a person experiences. That gap is where the interesting problems live, it is not going to be automated away, and it is the reason we test the way we do — automation first because it is fast and repeatable, then keyboard, then interactive states, then a person reading the screenshots.
The clean scan is where the work starts. It has never been where it finishes.
Fix the site, not just the score
Find out what is actually causing accessibility problems in your WordPress website — and what real remediation would involve.