If you start an accessibility audit with alt text, you might miss a fundamental accessibility error. The easiest error to spot and fix on a website is a missing or incorrect WCAG 3.1.1 Language of Page (Level A) tag. It’s incredibly damaging to a site’s overall usability while simultaneously being one of the simplest issues to remediate.

I audited a practice website I built specifically to test audits and provide skill samples. I instructed the AI that built it to add WCAG errors without telling me which ones or where they were, ensuring the audit process remained authentic operating the same way a real client site would.

What Is WCAG 3.1.1 Language of Page?

It is a Level A accessibility requirement that ensures the primary language of a webpage is defined using a valid language code on the HTML root tag (e.g., <html lang=”en”>). Declaring this attribute allows screen readers, translation tools, and browsers to correctly pronounce and display the site’s content automatically. 

Screen reader users are the group most directly affected by document language settings. Assistive technologies rely on language attributes to choose the correct pronunciation, voice rules, and accent for the entire document.

When a site uses an invalid or missing language value, the screen reader either falls back to a default system voice (mispronouncing every word) or fails to announce content altogether. This isn’t limited to one button or image; it impacts every single piece of text on the page.

What Does WCAG 3.1.1 Require?

The WCAG 3.1.1 (Level A) Success Criterion requires the root <html> element to declare a valid, standardized language code (such as lang=”en”) so browsers and screen readers know how to interpret and pronounce the page’s primary content from the moment it loads.

How to Test for WCAG 3.1.1

Testing for a broken or missing language attribute is fast, but it requires a careful manual check. 

I opened Chrome DevTools and inspected the page manually before running anything else. Most automated scanners can flag an invalid lang value, but it’s not foolproof, so I always confirm this specific error isn’t present before I do anything more involved.

Surprisingly, I’ve seen accessibility auditors make this mistake. It’s easy to skip past the very first line of markup when you’re focused on components further down the page.

How to Fix This Issue? 

To resolve the WCAG 3.1.1 issue, replace the missing or invalid tag with a valid language code.

Incorrect code: <html lang=”x-custom”>
Corrected code for general English: <html lang=”en”>
Corrected code for regional English: <html lang=”en-US”>

Plain “en” is fully valid and sufficient to pass WCAG 3.1.1. If any part of the page uses a different language further down, that specific element needs its own lang attribute too, since the root value only sets the document-wide default. 

How to Verify Your Fix

After making the change, I went back into DevTools and confirmed the root html tag now reads lang=”en” instead of the invalid value. 

The final verification step, which I’d recommend for any real audit, is a quick pass with a screen reader like NVDA or VoiceOver to confirm the page is read in the correct voice and pronunciation from the very first element. 

Why Does This Matter for Real Users?

A missing or broken language tag directly disrupts the experience for several groups of real users:

• Screen Reader Users: Ensures speech synthesis uses the correct accent, voice, and pronunciation rules instead of mispronouncing every word.
• Text-to-Speech Users: Helps individuals who struggle with word recognition, decoding text, or reading fluency follow along and comprehend written content smoothly.
• Non-Native Readers: Enables translation tools and speech software to assist users reading or processing content in a secondary language.
• Caption & Subtitle Viewers: Allows automated media tools to parse audio accurately, generate synchronized captions, and display reliable translations.

Summary Key Takeaways

• Find the easiest error first: Before starting an in-depth accessibility audit, check the document basics.
• Fix the basics first: Checking the lang attribute on the <html> tag takes seconds and prevents sitewide accessibility failures.
• Protect assistive tool users: Correct language codes ensure screen readers pronounce text properly across the entire website.
• Combine visual and functional fixes: Pair correct HTML tags with simple typography, safe motion settings, and strong color contrast to create a truly inclusive user experience.

Where Can You Learn More?

• Official Standard: WCAG 3.1.1 Language of Page, 
• Related LinkedIn post: WCAG 3.1.1 accessibility audit in action. 

Frequently Asked Questions

Is 3.1.1 a Level A or Level AA requirement?

It’s Level A, the most basic and mandatory tier of WCAG conformance. Sites claiming any level of WCAG compliance (A, AA, or AAA) must pass this criterion.

Does 3.1.1 apply to pages with multiple languages?

Yes, the <html> tag needs one primary declared language, but individual passages in a different language should be marked separately (e.g., <span lang=”es”>). This is distinct from 3.1.2 (Language of Parts), which governs those inline changes.

How do I test whether a page passes 3.1.1?

Check the <html> tag’s lang attribute in DevTools’ Elements panel or run an automated audit tool like axe DevTools or Lighthouse. Manual screen-reader testing (VoiceOver, NVDA) can confirm pronunciation is correct in practice.