Engineering
Common Lighthouse Accessibility mistakes that still ship
A green Accessibility audit score still ships with unlabeled controls, broken contrast, and pages never opened after render—common mistakes that treat the audit like a sticker.
· by Maya Okonkwo

Teams still treat an Accessibility audit like a sticker on the release ticket. The score looks fine on one URL. The public surface still exposes unlabeled icon buttons, contrast failures in late-mounted UI, and routes the audit never opened because nobody followed a link past the homepage.
SlaySlop's glossary names this check plainly: Accessibility audit "Runs automated accessibility checks in a rendered browser page." Automated. Rendered browser page. The mistakes below ignore one of those words and ship anyway.
Outcome if you catch these early
You ship with automated a11y findings tied to real routes, siblings like Accessible names and Document semantics tracked separately, and a handoff note that does not pretend a single score is a WCAG certificate.
Boundaries
Read-only observation. Permissioned scans. Not a pentest. Not a full assistive-tech user study. Accessibility audit sits under Accessibility with Accessible names ("Finds controls and content that lack usable accessible labels"), Document semantics ("Reviews structural signals that help assistive technology"), and Viewport configuration ("Checks mobile viewport setup and zoom-safe behavior"). Do not collapse those into one checkbox.
Loading diagram.
Mistake 1: auditing only the marketing homepage
The Performance and accessibility product flow is explicit: render key pages, run quality audits on discovered pages, attach findings to routes. A single homepage pass misses checkout, account settings, cookie banners mounted after consent, and docs routes that carry most of the interactive controls.
# Permissioned: remind yourself which routes matter before you call a11y done
printf '%s\n' \
"https://staging.example.com/" \
"https://staging.example.com/pricing" \
"https://staging.example.com/app/settings"If Linked pages discovery shows more public surface than you audited, the calm was incomplete.
Mistake 2: trusting a lab score without opening the rendered DOM
Automated checks need a finished page. App shells that hydrate late are where unlabeled buttons and missing landmarks appear. A static HTML fetch never sees them. Curl is fine for headers. It is the wrong observer for this signal.
wrong_observer: first HTML body only
right_observer: real browser after layout + script
signal: automated accessibility checks on rendered pageMistake 3: fixing the score, ignoring Accessible names siblings
Clearing an audit row by tweaking contrast on one component does not invent usable names on icon-only controls. Accessible names is a separate check. I still see teams close the "a11y" ticket because the audit percentage moved while the header still ships anonymous SVGs.
Mistake 4: treating Document semantics as optional polish
Landmarks and heading outline failures often sit beside the audit findings. Document semantics reviews structural signals assistive technology relies on. Shipping a prettier button color while <main> never appears is the wrong priority order. Product copy says start with the worst: inaccessible experiences before cosmetic cleanup.
Mistake 5: assuming mobile viewport is covered by the audit score
Viewport configuration is its own check: mobile viewport setup and zoom-safe behavior. Pinch-zoom locks and missing viewport meta are public-surface failures that embarrass you on a phone demo. Do not assume the Accessibility audit subsumed them.
Mistake 6: no permission, still scanning a stranger's site
SlaySlop runs read-only checks on public websites. Scanning a site you do not own, manage, or have permission to test violates Acceptable Use. Automated a11y output is still a scan. Get permission.
Mistake 7: equating automated checks with a conformance claim
The glossary says automated accessibility checks. That is not a WCAG audit with assistive-tech users. Report language should stay honest: automated findings on rendered pages, ranked with evidence, not a legal conformance badge.
Happy path that avoids the list
Open routes you are allowed to test in a real browser. Run the Accessibility audit in the same pass as names, semantics, and viewport. Triage by route. Fix anonymous primary actions and structure failures before palette nits.
Loading diagram.
Mistake 8: fixing staging, shipping a different production bundle
Consent tags, experiment scripts, and CMS blocks differ between environments. An Accessibility audit clean on staging can reopen on production when a third-party widget injects unlabeled controls. Re-check the production hostname you actually hand to the client, with permission, after the final bundle is live.
# Permissioned production sanity after release
curl -sI "https://www.example.com/pricing" | sed -n '1,8p'
# Then real-browser audit on the same pathRelated next step
If you want one browser pass that keeps performance and accessibility findings on the same routes, SlaySlop runs those quality audits after render and attaches evidence to the page where each issue appeared.