WCAG 3.1.2 Language of Parts — Testing Guide for Mobile & Web Apps

WCAG 3.1.2, "Language of Parts," is a critical accessibility criterion that ensures your application's content is understandable to users who rely on assistive technologies to translate or interpret l

Ensuring Global Reach: A Practical Guide to WCAG 3.1.2 Language of Parts

WCAG 3.1.2, "Language of Parts," is a critical accessibility criterion that ensures your application's content is understandable to users who rely on assistive technologies to translate or interpret language. At its core, this standard mandates that if a part of your content has a different language than the rest of your content, that specific part's language must be programmatically identified. This might seem straightforward, but its implications are far-reaching, impacting global users and those with specific assistive needs.

What WCAG 3.1.2 Requires

In plain terms, WCAG 3.1.2 states that any segment of text within your application that deviates from the primary language of the page or screen must be explicitly marked with its correct language. This applies to both content that is visually present and content that is only accessible via screen readers. The goal is to allow assistive technologies, such as screen readers and translation tools, to correctly interpret and present the content to the user.

For example, if your primary application language is English, but you have a Spanish phrase embedded within an English paragraph, that Spanish phrase needs to be identified as Spanish. This allows a screen reader to switch its pronunciation engine to Spanish for that specific phrase, ensuring it's spoken correctly. Similarly, translation tools can then accurately translate this identified segment.

Why WCAG 3.1.2 Matters

The impact of WCAG 3.1.2 extends beyond a simple compliance checkbox. It directly affects:

• International Users: Individuals browsing your app in a language other than their native tongue will encounter mispronounced words, incorrect grammar, and confusing translations if language changes aren't identified. This creates a significant barrier to comprehension and engagement.
• Users of Screen Readers: Screen readers rely on accurate language identification to select the appropriate text-to-speech voice and pronunciation rules. Incorrectly identified languages lead to garbled output, making the content unintelligible.
• Users of Translation Tools: Automated translation services are more effective when given clear linguistic boundaries. Unmarked language shifts can result in awkward and inaccurate translations.
• Search Engine Optimization (SEO): Search engines can better index and understand multilingual content when language attributes are correctly applied, improving discoverability for international audiences.

This criterion is a fundamental aspect of creating inclusive digital experiences, aligning with principles found in regulations like the European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA), which aim to ensure equal access to information and services.

Common Violations and Examples

Violations of WCAG 3.1.2 often occur in scenarios involving direct quotes, foreign language terms, or content dynamically loaded from different language sources.

Web Application Examples:

1. Direct Quotes:

• Violation: An English article includes a French quote: "The team decided to 'laissez-faire' their approach."
• Problem: A screen reader might attempt to pronounce "laissez-faire" with English phonetics, leading to confusion.
• Corrected:

  The team decided to laissez-faire their approach.

1. Technical Terms/Acronyms:

• Violation: An English document uses the German term "Schadenfreude" without marking its language.
• Problem: Incorrect pronunciation by screen readers.
• Corrected:

  The user experienced a sense of Schadenfreude.

1. Embedded Content:

• Violation: A product description in English includes a short Spanish product name or slogan that is not marked.
• Problem: Users expecting English may encounter unexpected language shifts in pronunciation.
• Corrected:

  Introducing the new "El Sol" (the sun) model, designed for ultimate comfort.

  becomes

  Introducing the new El Sol (the sun) model, designed for ultimate comfort.

Mobile Application Examples (Android/iOS):

1. User-Generated Content:

• Violation: A social media feed displays posts in various languages without proper language tagging. A user's comment in Portuguese appears in an otherwise English feed.
• Problem: Screen readers will try to read the Portuguese comment using English pronunciation rules.
• Corrected: The backend should ideally provide language metadata for user-generated content, which the app then uses to apply the lang attribute (or equivalent) to the text view. For example, a TextView displaying the Portuguese comment should have its android:textLocale attribute set to "pt".

1. Localization Snippets:

• Violation: A mobile app primarily in English displays a small disclaimer or error message in French that was not correctly localized or tagged.
• Problem: The assistive technology misinterprets the language, leading to an unintelligible message.
• Corrected: Ensure that when a snippet of text is in a different language, the underlying UI element's language property is set correctly. For Android, this might involve using setTextLocale() on TextView or ensuring the android:locale attribute is correctly set in XML layouts if applicable. For iOS, UILabel and UITextView generally inherit the language from the system or can be programmatically set if needed.

1. Brand Names/Slogans:

• Violation: An English-language app uses a foreign brand name or slogan without specifying its language. For example, a French cosmetic brand name "Belle Fleur" is displayed in an English app.
• Problem: Screen readers will attempt to pronounce "Belle Fleur" with English phonetics.
• Corrected: The TextView displaying "Belle Fleur" should have its locale set to French (fr).

Testing for WCAG 3.1.2 Compliance

Testing for this criterion requires a combination of manual inspection and automated tooling.

Manual Testing Steps:

1. Identify Language Shifts: Navigate through your application and look for any instances where text is not in the primary language of the screen or page. This includes direct quotes, foreign words, brand names, or dynamically loaded content.
2. Inspect HTML/XML: For web applications, use your browser's developer tools to inspect the HTML source. For mobile applications, you might use accessibility inspectors (like Android's Accessibility Scanner or Xcode's Accessibility Inspector) to examine the properties of UI elements.
3. Verify lang Attributes (Web): Check that any ,
   , or other elements containing text in a different language have a lang attribute set to the correct ISO 639-1 language code (e.g., lang="fr", lang="es").
4. Verify Locale Properties (Mobile): On mobile, check that the UI elements displaying foreign text have their language properties correctly set. For Android, this often means ensuring android:textLocale is set on TextView or similar. For iOS, it's about ensuring the text element's language context is correctly inferred or set.
5. Test with Screen Readers: Use a screen reader (e.g., VoiceOver on iOS, TalkBack on Android, NVDA or JAWS on desktop) to navigate through the identified sections. Listen carefully to the pronunciation of foreign words or phrases. Does it sound correct for the intended language?

Automated Tools:

• Browser Developer Tools: Chrome DevTools, Firefox Developer Edition, etc., can help inspect HTML structure and attributes.
• Linters and Automated Scanners: Tools like Axe-core, WAVE, and Lighthouse can identify missing lang attributes on the web.
• Mobile Accessibility Scanners: Android's Accessibility Scanner and Xcode's Accessibility Inspector can help identify issues with UI element properties, though specific language locale checks might be less granular.

Mobile-Specific Considerations:

• Platform Defaults: Both Android and iOS attempt to infer language based on device settings. However, this inference can fail for embedded content.
• Dynamic Content: If your app fetches content from APIs or databases, ensure that the API responses include language metadata, or that your app logic correctly identifies and tags the language of the displayed text.
• Localization Frameworks: Properly using your platform's localization frameworks (e.g., Android's resource files, iOS's .strings files) can help manage and apply language attributes correctly, but the responsibility remains to ensure the *correct* language is applied to specific snippets.

Fixing WCAG 3.1.2 Violations

The fix is generally to explicitly declare the language of the non-primary text.

Web Application Code Examples:

<!-- Violation: English text with French quote -->
<p>She said, "C'est la vie."</p>

<!-- Fix: Mark the French quote -->
<p>She said, <span lang="fr">C'est la vie</span>.</p>

<!-- Violation: English page with Spanish product name -->
<p>Our new product, "La Luna", is now available.</p>

<!-- Fix: Mark the Spanish product name -->
<p>Our new product, <span lang="es">La Luna</span>, is now available.</p>

Mobile Application Code Examples (Conceptual):

Android (Kotlin):

// Assuming 'textView' is your TextView instance
val frenchPhrase = "Bonjour le monde"
textView.text = frenchPhrase
// Set the locale for this specific text
textView.textLocale = Locale.FRENCH // Or Locale("fr")

iOS (Swift):

For UILabel or UITextView, the system generally handles language based on the text property and the device's locale. However, for explicitly setting a different language for a segment within a label, you might need to consider attributed strings and potentially more advanced text rendering techniques if the system's automatic inference isn't sufficient. Often, ensuring the text property is correctly populated with text *intended* for that language, and that the app's overall language is set correctly, is the primary approach. If specific segments *must* be programmatically tagged differently, investigate NSAttributedString with language attributes.

How SUSA Checks for WCAG 3.1.2 Compliance

SUSA's autonomous QA platform tackles WCAG 3.1.2 by integrating its exploration with accessibility and content analysis.

1. Autonomous Exploration: SUSA explores your application (APK or web URL) using various user personas, including those with specific language needs. During this exploration, it identifies and analyzes textual content.
2. Content Parsing and Language Detection: SUSA parses the DOM (for web) or UI hierarchy (for mobile) to extract text elements. It employs sophisticated language detection algorithms to identify the language of each text segment.
3. Attribute Verification:

• Web: SUSA checks for the presence and correctness of `lang