WCAG 3.1.1 Language of Page — Testing Guide for Mobile & Web Apps

June 29, 2026 · 6 min read · WCAG Guides

Ensuring WCAG 3.1.1 Compliance: Language of Page (Level A)

WCAG 3.1.1, "Language of Page," is a foundational accessibility requirement. Its core tenet is simple: clearly declare the primary language of your web page or application content. This isn't about complex linguistic analysis; it's about providing a clear signal to assistive technologies and browsers.

What WCAG 3.1.1 Requires

At its most basic level, WCAG 3.1.1 mandates that the default human language of each web page is programmatically determined. This means that browsers, screen readers, and other assistive technologies can understand what language the content is written in. This is typically achieved by setting the lang attribute on the tag for web content. For mobile applications, this translates to setting the appropriate locale for the application's UI elements.

Why WCAG 3.1.1 Matters

Incorrectly declared or missing language information creates significant barriers for users, especially those relying on assistive technologies.

Screen Reader Users: Screen readers use the language declaration to load the correct speech synthesizer. If the language is misidentified (e.g., a French page declared as English), the screen reader will attempt to read French with an English accent, rendering the content unintelligible. This directly impacts users who depend on screen readers for comprehension, a critical aspect for compliance with regulations like the EU EAA and ADA.
Translation Tools: Automatic translation services also rely on language detection. An inaccurate declaration can lead to incorrect or nonsensical translations, hindering users who need to access content in their preferred language.
Search Engines: Search engines use language metadata to index content appropriately, impacting discoverability for all users.
Visual Text Spacing: Some browsers adjust text spacing based on language. Incorrect declarations can lead to suboptimal visual presentation.

Common Violations and Examples

Violations of WCAG 3.1.1 often stem from oversight or a lack of understanding of its importance.

#### Web Application Examples

Missing lang Attribute:

Violation: The tag lacks the lang attribute entirely.
Example:


        <!DOCTYPE html>
        <html>
        <head>
            <title>My Website</title>
        </head>
        <body>
            <h1>Welcome!</h1>
        </body>
        </html>

Impact: Assistive technologies default to the user's system language, which may not match the page's content.

Incorrect lang Attribute Value:

Violation: The lang attribute is present but set to an incorrect language code.
Example:


        <!DOCTYPE html>
        <html lang="en-US"> <!-- Page content is actually in Spanish -->
        <head>
            <title>Mi Sitio Web</title>
        </head>
        <body>
            <h1>¡Bienvenido!</h1>
        </body>
        </html>

Impact: A screen reader might announce "Welcome" with a Spanish accent, or attempt to read Spanish as if it were English, causing confusion.

Dynamic Content Mismatch:

Violation: The primary lang attribute is set correctly, but significant portions of dynamically loaded content are in a different language without proper declaration for those specific sections.
Example: A news site primarily in English () loads a widget with breaking news alerts in French.
Impact: Screen readers may announce the French alerts in English, making them incomprehensible.

#### Mobile Application Examples (Android/iOS)

Mobile applications don't have an tag, but the principle remains the same. The application's declared locale dictates how UI elements are rendered and interpreted.

App Not Localized:

Violation: An application is developed and deployed without any localization, defaulting to the developer's primary language (often English).
Example: An app developed in the US is distributed globally, with all button labels, error messages, and navigation text remaining in English, even when the user's device is set to Spanish.
Impact: Users whose device language is not English will see English text, hindering their ability to understand and use the app. This is particularly problematic for users in regions covered by the EU EAA or ADA, where language access is a legal requirement.

Incorrect Locale Configuration:

Violation: The app's configuration incorrectly specifies the locale, leading to the wrong language resources being loaded.
Example: An app intended for a German audience (de-DE) is mistakenly configured to load French (fr-FR) resources.
Impact: Users will see French UI elements on an app that should be in German, causing significant confusion and usability issues.

How to Test for WCAG 3.1.1 Compliance

Testing for WCAG 3.1.1 is relatively straightforward, combining manual checks with automated tools.

#### Manual Testing Steps

Web:

Inspect Source Code: Open your web application in a browser, right-click, and select "View Page Source" (or similar). Locate the declaration and the tag. Verify that the lang attribute is present and set to the correct ISO 639-1 language code (e.g., en for English, es for Spanish, fr for French).
Check for Mixed Languages: If your application has dynamic content or sections that might be in different languages, manually review these areas. Ensure that if a significant portion of content is in a different language, it's either correctly declared using lang on specific elements (e.g., ...) or handled by the application's localization strategy.

Mobile (Android/iOS):

Device Language Setting: Change your device's primary language to a language other than the one you primarily developed in.
Launch Application: Open your application.
Verify UI Text: Observe all visible text elements: button labels, navigation titles, error messages, headings, and any other UI components. Ensure they are displayed in the language you set on your device. If your app supports multiple languages, test switching between them within the app's settings and verify the UI updates correctly.

#### Automated Tools

Web:
Browser Developer Tools: Most modern browsers have accessibility panels in their developer tools that can flag missing or incorrect lang attributes.
Online Validators: Tools like the WAVE Web Accessibility Evaluation Tool or the AXE accessibility engine (available as browser extensions and CLI tools) can automatically detect missing lang attributes.
Linters and Scanners: Static analysis tools and CI/CD integrated scanners can be configured to check for the presence and validity of the lang attribute.
Mobile:
Android Studio/Xcode: During development, these IDEs provide tools for managing and verifying string resources and localization settings.
Accessibility Scanners: While less common for lang specifically compared to web, some advanced mobile accessibility testing tools might offer checks for proper locale handling.

#### Mobile-Specific Considerations

Resource Files: On Android, ensure your res/values/ directory has a strings.xml file for the default language and separate values-/strings.xml files for other supported languages (e.g., values-es/strings.xml for Spanish). Similarly, on iOS, ensure your Localizable.strings files are correctly organized by language.
Device Locale vs. App Locale: Understand how your application interacts with the device's locale settings. Most apps should follow the device's primary language setting by default.

How to Fix Violations

#### Web Application Fixes

Add or Correct lang Attribute:
Code Example:


        <!DOCTYPE html>
        <html lang="en"> <!-- For English content -->
        <head>
            <title>My Website</title>
        </head>
        <body>
            <h1>Welcome!</h1>
        </body>
        </html>

or for Spanish:


        <!DOCTYPE html>
        <html lang="es"> <!-- For Spanish content -->
        <head>
            <title>Mi Sitio Web</title>
        </head>
        <body>
            <h1>¡Bienvenido!</h1>
        </body>
        </html>

Handle Mixed Languages: For specific sections in a different language:


    <p>Here is some English text.</p>
    <p lang="fr">Et voici du texte en français.</p>

This approach is generally less preferred than ensuring the entire page's primary language is declared correctly and using proper internationalization frameworks for dynamically loaded content.

#### Mobile Application Fixes

Implement Localization:
Android: Create strings.xml files for each supported language in the appropriate values- directories. Ensure your app's manifest and code correctly reference these resources.
iOS: Use Localizable.strings files for each language. Ensure your project is configured to support these languages in the project settings and that your code uses NSLocalizedString or similar methods to retrieve localized strings.
Set Default Locale: Configure your app to default to the device's language setting. If the device language is not supported, fall back to a predefined default language (e.g., English).

How SUSA Checks This Criterion

SUSA (SUSATest) autonomously verifies WCAG 3.1.1 compliance as part of its broad accessibility testing suite.

Web Testing: When you provide a web URL to SUSA, it analyzes the HTML structure. It specifically checks for the presence and correctness of the lang attribute on the tag. SUSA flags any pages missing this attribute or using an invalid language code.
Mobile Testing (APK Upload): For Android APKs, SUSA's autonomous exploration simulates user interactions. It identifies the primary language used in the application's UI elements. If the app's declared locale doesn't align with the language of the UI text it encounters, or if the app exhibits a lack of localization when the device's language is set to a different one, SUSA will report this as a violation. This is part of its dynamic testing, ensuring that the app behaves correctly across different simulated user environments, including varying device language settings.
Persona-Based Testing: SUSA's diverse user personas, such as the "Novice," "Student," or "Elderly" user, can indirectly highlight language issues. If a persona is set to a non-English language and the app consistently presents

Test Your App Autonomously

Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.

Try SUSA Free

WCAG 3.1.1 Language of Page — Testing Guide for Mobile & Web Apps

Ensuring WCAG 3.1.1 Compliance: Language of Page (Level A)

What WCAG 3.1.1 Requires

Why WCAG 3.1.1 Matters

Common Violations and Examples

How to Test for WCAG 3.1.1 Compliance

How to Fix Violations

How SUSA Checks This Criterion

Test Your App Autonomously

Related Articles

WCAG 1.4.11 Non-text Contrast — Testing Guide for Mobile & Web Apps

WCAG 1.2.4 Captions (Live) — Testing Guide for Mobile & Web Apps

WCAG 1.4.3 Contrast (Minimum) — Testing Guide for Mobile & Web Apps

WCAG 1.2.5 Audio Description — Testing Guide for Mobile & Web Apps