GazeSiteTest your website →
The Missing lang Attribute and the Users It Confuses
One missing attribute makes screen readers mispronounce your entire site, and the fix is a single word.
There’s a class of bug I think of as invisible to the author. The site works perfectly for the person who built it, and fails for someone they will never meet, in a way they will never witness. The missing lang attribute is the purest example I know.
Here’s the setup. Every HTML document starts with an <html> tag, and that tag can carry an attribute declaring what language the page is written in: <html lang="en"> for English, lang="pl" for Polish, lang="de" for German. When it’s missing, the page still renders. Nothing looks wrong. Every visual test passes. And yet the page is broken for anyone who experiences it through software that needs to know the language, which is more people than you’d guess.
The clearest case is screen readers. A screen reader is a program that converts the page to synthesized speech, and speech synthesis is language-specific. English text read with French pronunciation rules is not accented English; it’s closer to gibberish. The vowels are wrong, the stress is wrong, silent letters get voiced. When the page doesn’t declare its language, the screen reader has to guess, typically falling back to the user’s system language. So a French-speaking user visiting your English site may hear the whole thing pronounced as if it were French. Imagine your site read aloud by someone who has never seen English and is sounding it out using the spelling rules of another language. That’s the actual experience you’re shipping.
Notice who gets hurt worst: not your average visitor, but the visitor who is both blind and international. The intersection of two groups you’re least likely to have on your team, testing your site. That’s exactly why the bug survives. Bugs get fixed when someone who can fix them feels the pain. This one is arranged so that never happens naturally.
Screen readers aren’t the only software that wants to know your language. Browsers use the declaration to decide whether to offer translation, so a missing or wrong lang can mean your English page gets an unprompted, mangled machine translation, or a visitor who needs translation never gets offered it. Hyphenation in CSS depends on it, because where you can break a word differs by language. Even fonts can render differently, since some characters have different correct forms in different languages and the lang attribute is how the browser picks. None of this is exotic. It’s basic plumbing that most of the web’s text-processing machinery reads from that one attribute.
The failure has a stranger cousin: the wrong lang. This usually comes from a template. Someone builds a site from a theme whose boilerplate says lang="en" and fills it with, say, Spanish content, or the reverse. Now the page isn’t silent about its language, it’s lying, which is worse. The screen reader confidently applies the wrong pronunciation. The browser confidently offers to translate English into English. I see this in GazeSite scans often enough that I’ve stopped being surprised: the attribute is present, inherited from a boilerplate nobody read, and wrong.
There’s also a subtler skill here, which is marking language changes within a page. If your English page quotes a sentence of German, you can wrap it in an element with lang="de" and a screen reader will switch pronunciation for just that passage. WCAG treats the page-level declaration and the passage-level one as separate requirements, and honestly, if you only do the first, you’ve handled most of the problem. But it’s worth knowing the mechanism exists, because bilingual sites, menus with foreign dish names, testimonials in other languages, all read dramatically better with it.
The business case is the same one that applies to all of accessibility, but sharpened. If you sell internationally, or want to, the users confused by a missing lang attribute are disproportionately your international users, the exact people your expansion plans depend on. And unlike most internationalization work, which is genuinely expensive, this costs one word. I keep coming back to that asymmetry. Translating a site is a project. Declaring what language it’s already in is a keystroke.
Which raises the question of why it’s so often missing, and I think the answer says something about how we build software. Nobody decides to omit the lang attribute. It’s omitted by default, by hand-written boilerplate, by old generators, by the copy-paste chain of tutorials descended from other tutorials. Absences don’t show up in code review the way mistakes do. You can stare at an <html> tag for a long time without noticing what isn’t there. This is, incidentally, the argument for auditing your site with a tool rather than your eyes; tools are exactly as good at seeing absences as presences, and eyes are not.
So: view the source of your homepage, right now, and look at the first tag. If it says <html lang="..."> with the right language, you’re done, and it cost you thirty seconds. If not, the fix is one edit in one template file, and somewhere a stranger’s screen reader will start speaking your site in a language instead of a noise. You will never see it happen. That’s the whole point.
More articles
Ranking gets you onto the results page; the title tag is what gets you off it.
Read →Size, contrast, and position tell visitors what to read first, and a page that ranks nothing communicates nothing.
Read →An audit finding is only worth money if you can trace it to a visitor who would have paid you and didn't.
Read →