I ran a real accessibility audit on a major retailer. Four of my first five findings were wrong.

A worked example using the Conformant audit method. Site: zalando.co.uk (UK homepage). Tested 11 August 2026, Chrome on Windows, 1568×705 viewport, unauthenticated. Every result below is reproducible in browser DevTools.

Why publish this

I sell an accessibility audit kit. You have never heard of me. The reasonable response to that is scepticism, and the only useful answer is to show the method working on a real site rather than describe it.

I picked a large, well-resourced European e-commerce site — the exact kind of site my buyers get asked to audit, and one squarely in scope of the European Accessibility Act. I did not pick a soft target, and I did not go looking for a hit piece.

The result was not what makes for good marketing: the site is well built. I found a small number of genuine issues and, more instructively, I generated a pile of false findings that a careless auditor would have shipped to a client. That second part is the actual lesson, so it gets most of the space here.

What I could and could not test

Being precise about this is not throat-clearing; it is the difference between an audit and a guess.

So this is roughly the first 40% of a real audit on one template. A genuine engagement covers 10–16 templates and every step of checkout. Anyone presenting what follows as "an accessibility audit" would be overselling it, and that includes me.

Part 1 — The four false findings

False finding 1: "Footer headings leak icon-font text"

My first structural pass returned footer headings reading:

helpHelp and Contact
gift_cardGift Cards
zalando_logo_outlinedAbout us
truckOur partners
credit_cardOur payment methods

That looks like a textbook failure — icon ligature tokens glued to real heading text, which a screen reader would read aloud as "help Help and Contact". Seven headings affected. It is specific, it is embarrassing, and it would have gone straight into a report.

It is wrong. textContent is not the accessible name.

Re-running the check with an accessible-name computation that respects aria-hidden and display:none gives:

The icon elements carry aria-hidden="true" and role="presentation". They are correctly hidden. The doubling was a second, hidden responsive copy of the footer — also correctly excluded.

Lesson: any tool or script that reads textContent will produce this false positive. Verify against the accessibility tree, every time.

False finding 2: "149 touch targets are below 24×24 pixels"

WCAG 2.2 added 2.5.8 Target Size (Minimum) at Level AA, and my scan found 149 visible interactive elements under 24 CSS pixels in one dimension. A large, alarming number.

Looking at what they actually were:

A 100x15  "Help and contact"
A 298x15  "Free standard delivery over £39.00 & free returns*"
A 121x15  "30-day return policy"

These are inline text links in sentences — an explicit exception in 2.5.8. Filtering to non-inline controls collapses the number to a handful.

Lesson: 2.5.8 has exceptions and they matter. Reporting the raw count would have been the fastest possible way to prove to a technical client that I had not read the criterion.

False finding 3: "The search field has autocomplete disabled"

The site search input carries autocomplete="off". On a checkout address field that is a straight 1.3.5 Identify Input Purpose failure and one of the most common findings in retail audits.

But 1.3.5 applies to fields collecting information about the user. A site search box collects a query, not user data. It is out of scope, and autocomplete="off" is arguably correct there.

Lesson: know which criterion applies before you cite it.

False finding 4: "Two header buttons have no accessible name"

Two 40×40 <button> elements with SVG content, no aria-label, no <title>, no text. Classic unnamed icon button, 4.1.2, Level A.

Inspecting further: opacity: 0, pointer-events: none, aria-hidden="true". Carousel scroll controls, hidden when not applicable, correctly removed from the accessibility tree.

Lesson: an element with no accessible name is only a defect if it is exposed to users at all.

And one check that could not answer the question

I tried to detect suppressed focus indicators by parsing stylesheets for :focus { outline: none }:

css_rulesInspected: 40
css_sheetsBlockedByCORS: 5
css_focusOutlineRemoved: 0
css_focusVisibleRules: 0

Five of the site's stylesheets are cross-origin and unreadable from script. The check inspected almost nothing and returned a clean result. A clean result from a check that could not run is the most dangerous output in this entire exercise — it looks identical to a pass.

The only way to answer 2.4.7 was to press Tab and look. Which is the whole argument.

Part 2 — What the site does well

Verified, not assumed:

• Three skip links, in sensible order: "Skip to main content", "Skip to search", "Skip to [brand]". Most sites have zero or one.
• Visible focus indicator — a 1px inset black box-shadow, confirmed in computed styles and visually. Black on white is far above the 3:1 non-text contrast floor. Thin, but 2.4.7 asks for visible, not thick — thickness is 2.4.13, which is AAA.
• Complete landmark structure — one main, three nav, banner, contentinfo, and a search landmark.
• lang="en-GB" on the UK storefront, correctly localised rather than a global en.
• No positive tabindex anywhere.
• Zero images missing alt out of 16, with 10 correctly using alt="" for decorative images — evidence of deliberate decisions rather than a linter.
• Two live regions present, suggesting dynamic updates were considered.

That is a better baseline than the large majority of e-commerce sites.

Part 3 — The genuine findings

Graded by confidence, because not everything survives remote testing.

F-001 · Invisible controls may remain keyboard-focusable

Confidence: candidate — needs a human keyboard pass · 2.4.7 Focus Visible (AA) / 4.1.2 (A)

The page contains multiple carousel-arrow buttons at opacity: 0. Their handling is inconsistent: one carries aria-hidden="true" with tabindex="-1" (correct), while others have neither — meaning they remain in the tab order while invisible.

If confirmed, a keyboard user tabs onto a control they cannot see.

Why only a candidate: these may transition to opacity: 1 on :focus-visible, which would resolve it entirely. I could not verify that remotely. A human presses Tab and knows in ten seconds.

F-002 · Search field relies on placeholder text for its label

Confidence: confirmed · 3.3.2 Labels or Instructions (A)

No <label>, no aria-label, no title. The accessible name comes from placeholder="Search".

Placeholder is a valid last-resort fallback in the accessible-name algorithm, so this is not a clean 4.1.2 failure. It is a 3.3.2 concern: the label disappears the moment the user types.

Fix: add a visually hidden <label for> or aria-label="Search", keep the placeholder as a hint.

F-003 · Newsletter email field has no autocomplete

Confidence: confirmed · 1.3.5 Identify Input Purpose (AA)

Collects an email address — information about the user — with no autocomplete attribute.

Fix: autocomplete="email". One attribute.

F-004 · No h1 on the homepage

Confidence: confirmed as fact; advisory as a finding

The heading outline begins at <h2>. Fifteen visible headings, no <h1>.

Be precise: no WCAG success criterion mandates an <h1>. Anyone citing this as a Level A failure is wrong. It sits under 1.3.1 and 2.4.6 as a structural quality issue — screen reader users commonly press 1 to find the main heading, and there is nothing to find.

F-005 · Consent banner obscures content — check focus behaviour

Confidence: observed visually; needs keyboard confirmation · 2.4.11 Focus Not Obscured (AA, new in 2.2)

A large consent dialog covers roughly the lower third of the viewport on load. 2.4.11 requires that a focused element is never entirely hidden by author-created content. Consent layers are where this most often fails.

Summary

Ratio of false to genuine findings on the automated pass: 4 to 3. On a site better built than most.

That is the honest case for manual testing, and it cuts both ways. Automation misses real failures — but it also invents failures that are not there, and the invented ones are what destroy your credibility in front of a client's engineering team.

Notes on this write-up

Testing was limited to reading publicly served markup and pressing keyboard keys on a public page — no accounts, no orders, no automated crawling, no load of any kind. Findings are reported as of 11 August 2026 and may already be fixed; sites change constantly, which is precisely why a conformance claim is always a statement about a specific date.

This is not legal advice, not a compliance determination, and not a certification. It is a partial technical assessment published to demonstrate a method. If anyone at the company would like the raw evidence, it is theirs on request.