I broke Google Support last week. Or rather, I proved it was already broken.
Not in English. In English it works fine. Lighthouse gives it a decent score, axe-core agrees, everyone moves on.
I checked the Japanese version.
The HTML tag said lang="en". On a page written entirely in Japanese. Every ARIA label — Search, Close, Main menu — was still in English. The search placeholder said "Describe your issue" in English. The page title said "Google Help" in English.
Sixty accessibility attributes on the Japanese page were never translated.
A blind person using a Japanese screen reader on that page would hear English words randomly mixed into Japanese audio. The screen reader sees lang="en", switches to an English voice, and tries to pronounce Japanese characters with English rules. Complete mess.
And the kicker: Lighthouse says the page is fine.
Why Lighthouse misses it
Lighthouse checks whether an aria-label exists. It does not check what language it is in. So aria-label="Search" on a Japanese page gets a green checkmark because the attribute is present.
Same with alt text. Same with placeholders. Same with the lang attribute — Lighthouse checks that lang exists on the html tag, but not whether it matches the actual content language.
To find these issues, you have to do something no tool currently does: open the same page in two languages and compare the accessibility attributes side by side.
That is what I spent the last few days building.
What I built
Locali11y fetches the English and Japanese (or any other language) versions of the same page. It parses both with Cheerio — no browser needed, just raw HTML parsing. Then it runs twenty checks that are specifically designed around what breaks during translation.
Not generic WCAG checks. Targeted questions like:
Is the aria-label on this button identical to the English version? If yes, it was probably never translated.
Does the html lang attribute match the page locale? If the page is in Japanese but lang says "en", something went wrong in the deployment.
Is the placeholder text the same as the English page? Is the page title? The meta description?
These are simple string comparisons. The code that does the core detection is about twenty lines. It collects all ARIA labels from the English page, then checks each label on the translated page to see if it matches. If a Japanese page has aria-label="Search" and the English page also has aria-label="Search", that label was never localized.
No machine learning. No complex parsing. Just a comparison nobody built into a tool before.
What I found on real sites
Google Support: 60 locale-specific issues on the Japanese page. Score dropped from 84 to 71. The html lang bug is the worst one — it affects how the entire page is announced by screen readers.
IKEA Japan: carousel buttons saying "See previous items" and "See next items" in English on a Japanese page. Those are navigation controls that blind users rely on.
The pattern was the same everywhere I tested. Teams translate the visible content — headings, paragraphs, button text. They forget the invisible stuff — ARIA labels, alt attributes, placeholder values, metadata. And no tool in the standard workflow catches the gap because every tool checks one page at a time.
The technical choices
I used Cheerio instead of Playwright because the attributes I care about exist in the static HTML. Running a full browser for each page would add thirty seconds per locale and create deployment headaches. Cheerio parses HTML in milliseconds.
The app is built with Next.js and uses Supabase for storing audit results. The scoring groups issues by check type so that one category (like missing alt on fifty product images) cannot tank the entire score alone.
I used Lingo.dev for the app's own translations. The tool itself works in English, Spanish, Japanese, and Chinese. Building a localization auditor with poor localization would have been embarrassing.
What surprised me
Browsers do not fix this problem. Chrome's translate feature changes visible text on a page. It does not touch HTML attributes. So even if you translate a page with Chrome, the aria-labels stay English. There was a Chrome bug filed about this in 2019. In 2023 it regressed. As of mid-2025, no major browser reliably translates hidden accessibility attributes.
The EU Accessibility Act requires accessible digital products across all supported languages. Having lang="en" on a Japanese page is a compliance issue. Most companies have no idea this is happening on their sites because no tool checks for it.
What is missing
Locali11y currently checks one page per locale. A full site crawler would be more useful but was too complex for the hackathon timeline. The scoring system is simple and approximate. The fix suggestions use AI and would need human review for production use.
If someone forks this, the most useful next step would be CI integration — running these checks automatically on every deploy and failing the build when locale accessibility drops below a threshold.
Links
Live: https://locali11y.vercel.app/en
Code: https://github.com/Vaibhav13Shukla/locali11y
Video: https://youtu.be/dWck2xBytMs
Built for the Lingo.dev Multilingual Hackathon #3. App localization powered by Lingo.dev.
Top comments (0)