Resources

WCAG Fix It: 3.1.1 Language of Page

 

Table of Contents


Free Audit

If your website has text and they all do, WCAG 3.1.1 – Language of Page applies to you.

In this WCAG Fix It guide, we’re breaking down a technical requirement that has a huge impact on accessibility: ensuring the primary language of your web page can be programmatically determined.

It’s one line of code, but without it, assistive technology may mispronounce content, misinterpret meaning, or struggle to present characters correctly.

What Is WCAG 3.1.1?

WCAG 3.1.1 – Language of Page requires that the default human language of each web page is programmatically defined.

In simple terms, your website must clearly tell browsers and assistive technologies what language the page is written in.

This is done using the lang attribute in the <html> tag.

For example:

<html lang=”en”>

This tells user agents that the page is written in English.

How to Comply with WCAG 3.1.1

To meet this requirement:

Add the correct language attribute to your HTML document.

Examples:

English:

<html lang=”en”>

Spanish:

<html lang=”es”>

French:

<html lang=”fr”>

German:

<html lang=”de”>

This must appear in the root <html> element at the top of your page.

Why Language of Page Matters

Screen readers rely on language settings to:

  • Apply correct pronunciation rules
  • Use proper speech patterns and accents
  • Interpret abbreviations correctly
  • Handle character sets accurately

Without the correct lang attribute, a screen reader may:

  • Read Spanish content using English pronunciation
  • Mispronounce names
  • Struggle with non-Latin scripts
  • Create confusing or incorrect speech output

For multilingual users, this becomes frustrating fast. Language metadata is not visual, but it is essential.

The Human Impact of Missing Language Metadata

Imagine a Spanish-speaking user navigating a page written in Spanish.

But the lang attribute is missing.

Their screen reader defaults to English pronunciation.

Now everything sounds incorrect.

Words are distorted, Sentences lose their meaning and the experience feels broken and not natural for the user.

Or imagine content written in Arabic or Japanese without correct language tagging.

Characters may display correctly visually, but pronunciation and processing fail.

Users should not have to manually adjust settings to make your website usable.

When the language isn’t defined, accessibility suffers immediately.

Common WCAG 3.1.1 Failures

Here’s what we typically see when scanning websites:

  • No lang attribute defined
  • Incorrect language declared (e.g. lang=”en” on a Spanish site)
  • Template pages missing language metadata
  • Dynamically generated pages without proper language settings
  • Multilingual sites using only one global language declaration

All of these can fail WCAG 3.1.1.

How to Fix Missing or Incorrect Language Attributes

Add the lang Attribute to the HTML Tag

Locate the top of your HTML document.

If it looks like this:

<html>

Update it to:

<html lang=”en”>

Replace “en” with the correct primary language code.


For Multilingual Websites

If your page contains content in multiple languages, the default page language should still be declared at the root level.

For specific language changes within the page, use:

<span lang=”es”>Hola</span>

This ensures assistive technologies switch pronunciation correctly when needed.


If You’re Using a CMS

Most modern platforms automatically set the lang attribute based on your site’s language settings.

In WordPress, Shopify, Wix, and similar systems:

  • Check your site language settings
  • Ensure your theme outputs the correct lang attribute
  • Test the page source to confirm

If unsure, right-click your page, select “View Page Source,” and check the opening <html> tag.


How to Test WCAG 3.1.1

After updating the language attribute:

  • Re-run your accessibility scan
  • Confirm 3.1.1 is no longer flagged
  • Inspect the page source to verify the lang attribute
  • Test using a screen reader

Ask:

  • Is the correct pronunciation being used?
  • Does assistive technology interpret characters properly?

If yes, you’ve fixed it.

Why WCAG 3.1.1 Matters Beyond Compliance

Defining page language:

  • Improves screen reader accuracy
  • Supports multilingual users
  • Ensures correct pronunciation
  • Improves character rendering
  • Enhances search engine understanding
  • Reduces legal risk

It’s one small technical detail, but without it, accessibility can fall apart immediately.

WCAG 3.1.1 Quick Fix Checklist

The <html> tag includes a valid lang attribute
The declared language matches page content
Multilingual sections use proper language tags
Language settings verified in CMS
Page re-tested after updates

WCAG 3.1.1 Language of Page Frequently Asked Questions

What is WCAG 3.1.1 Language of Page?

WCAG 3.1.1 requires that the primary language of a web page can be programmatically determined using the HTML lang attribute.

Where should the lang attribute be added?

The lang attribute must be added to the root <html> element at the top of the page.

What happens if I don’t define the page language?

Screen readers may use incorrect pronunciation rules, causing mispronunciation and confusion for users.

Does this apply to multilingual websites?

Yes. The default page language must be defined, and specific sections in different languages should use the appropriate lang attribute within the content.

Related Content

WCAG Fix It: 4.1.2 Name, Role, Value

If your website has buttons, forms, menus, dropdowns, or interactive components, WCAG 4.1.2 applies to you. In this WCAG Fix It guide, we’re breaking down one of the most technical-sounding, yet critically important accessibility requirements: ensuring that interactive elements have a proper, programmatically defined name, role, and value. It sounds developer-heavy burut at its core,

Read more: WCAG Fix It: 4.1.2 Name, Role, Value

WCAG Fix It: 3.3.2 Labels or Instructions

If your website has forms, contact forms, checkout forms, booking forms, login forms, WCAG 3.3.2 applies to you. In this WCAG Fix It guide, we’re breaking down one of the most common and preventable accessibility failures: missing labels or unclear instructions. When users don’t know what information is expected in a field, forms become frustrating,

Read more: WCAG Fix It: 3.3.2 Labels or Instructions

WCAG Fix It: 2.4.4 Link Purpose (In Context)

If your website uses links like “Click here” or icon-only buttons, and it probably does, WCAG 2.4.4 applies to you. In this WCAG Fix It guide, we’re breaking down a common accessibility issue: unclear link purpose. It might seem small. Just a few words in a hyperlink, but when link text isn’t meaningful, navigation becomes

Read more: WCAG Fix It: 2.4.4 Link Purpose (In Context)