Earshot

Automated accessibility scanners like axe-core catch roughly a quarter to a third of real barriers, they'll pass alt="image123" without blinking, and can't tell if a page's reading order actually makes sense to a blind user. The rest needs a human with a screen reader, which doesn't scale. Working with a teammate over a hackathon, I built Earshot, a pipeline that scans a real site, proposes automated fixes, and verifies each one by converting the page into the literal narration a screen reader would produce and asking an LLM whether a blind user could actually understand and navigate it, refusing outright to claim a site is "fixed" or "compliant" anywhere in its output.

A verifier bug marked every non-throwing patch revert as successful even when the DOM had shifted underneath it and the revert silently no-op'd, caught by asking directly whether reverting actually restored the page and fixed in a follow-up commit. A deterministic 'add a landmark region' fix that looked obviously safe actually made a real government site's violations worse, and the set-diff verification step, not a naive before/after count, is what caught it. Running the tool against its own results dashboard turned up a real accessibility bug in its own UI: zero axe violations but a failing comprehension score, because a value and its label weren't programmatically associated, something no axe rule checks for at all.

Run against five real targets, the pipeline proposed dozens of patches; only a small fraction survived verification and stayed applied, the rest were automatically reverted for introducing a new violation, or the site's violation count held flat. That low keep-rate is the honest, checked-in result, and it's the argument for why verification has to be automatic: a patch that looks correct in isolation regularly isn't once it's actually re-checked against the live page.