Skip to content

A11y 101: 3.1.1 Language of Page

Last updated on April 14, 2026

Imagine walking into a restaurant in a foreign country. The menu is beautiful; elegant typography, gorgeous layout, mouth-watering descriptions. There’s just one problem: you don’t speak the language. You point at something random and hope you didn’t just order the sheep’s stomach stew.

Now imagine you’re a screen reader. You arrive at a webpage. The content is beautifully written, semantically structured, perfectly accessible. There’s just one problem: nobody told you what language it’s in. So you start reading it in your default voice with all the wrong pronunciation rules. Suddenly, a French phrase like “c’est la vie” comes out sounding like “sest la vye.” A Spanish name gets mangled beyond recognition. The user is confused. The content is misunderstood. The sheep’s stomach stew arrives at the table.

Sheep's stomach stew
Photo by Rachel Claire on Pexels.com

Your page needs to declare its tongue.

This is exactly why WCAG 3.1.1: Language of Page exists.

The Translation Game

The requirement is simple but powerful: The default human language of each web page must be programmatically determinable.

In code terms, this means slapping a lang attribute on your <html> element:

<html lang="en">

That’s it. One attribute. Two little characters. But those two characters tell browsers, screen readers, and translation tools exactly what language they’re dealing with. It’s like handing your assistive technology a dictionary before it starts reading aloud.

Without it, you’re leaving the interpretation up to guesswork. And assistive technologies are notoriously bad guessers.

Why This Matters: The Accent Problem

Here’s the thing about screen readers: they’re multilingual, but they’re not psychic. They can switch languages on the fly—but only if they know which language to switch to.

When you don’t declare the language, the screen reader applies its default pronunciation rules to everything. English text read with a German accent. Japanese characters pronounced using English phonetics. It’s not just awkward; it’s incomprehensible.

For users who are blind or have low vision, this turns readable content into an auditory puzzle. They have to mentally “re-translate” what they’re hearing back into something that makes sense. That’s cognitive load nobody asked for.

The Ripple Effect

The lang attribute doesn’t just help screen readers. It also:

  • Tells browsers which hyphenation rules to apply
  • Helps search engines index your content correctly
  • Enables automatic translation tools to recognize the source language
  • Improves font rendering for certain character sets

How to Lose the Language Game

I’ve seen this go wrong in a few predictable ways:

  1. The Missing Attribute: The page has no lang attribute at all. The screen reader guesses. It guesses wrong.
  2. The Wrong Code: The page is in French, but the lang attribute says en. Now your French content is being read with an English accent. Très mal.
  3. The Empty Declaration: The attribute exists but has no value: <html lang="">. That’s not a language; that’s a shrug.

The Fix Is One Line

Seriously. One line of code:

<!DOCTYPE html>
<html lang="en">
<head>
    ...

If your page is in Spanish, use lang="es". Japanese? lang="ja". British English? lang="en-GB". The ISO language codes are your friends here.

At its core, 3.1.1 is about respecting the user’s experience.

When you declare your page’s language, you’re saying: “I want you to understand this content the way it was meant to be understood.” You’re removing a barrier. You’re eliminating confusion. You’re making sure that when someone hears your content, they hear it correctly.

That’s not just accessibility. That’s hospitality.

Published ina11ya11y 101accessibilityADAblindcognitiondevelopmentEAAEN 301 549TestingW3CWCAGWeb Content Accessibility Guidelines

Comments are closed.