WCAG 1.2.3 Audio Description or Media Alternative — Testing Guide for Mobile & Web Apps

WCAG 1.2.3: Ensuring Media Alternatives for Audio Description

WCAG 1.2.3: Ensuring Media Alternatives for Audio Description

WCAG 1.2.3, at Level A, mandates that for any audio content in a video, a text alternative must be provided. This alternative can be either an audio description of the visual information or a media alternative that synchronizes text descriptions with the audio. This ensures users who cannot see the video content can still understand what is happening.

Why WCAG 1.2.3 Matters

This criterion directly impacts users with visual impairments, including those who are blind or have low vision. Without audio descriptions, these users are excluded from understanding the narrative or essential information conveyed visually in videos. For instance, a user watching a product demonstration video would miss crucial details about the product's features if those features are only shown and not described.

Beyond direct visual impairment, this also benefits users in situations where they cannot watch the video, such as when their device is not in a visual mode, or when they are multitasking. Compliance is not just about accessibility; it's about broader usability and inclusivity, aligning with legal requirements like the EU EAA (European Accessibility Act) and the ADA (Americans with Disabilities Act) which mandate accessible digital content.

Common Violations and Examples

Violations of WCAG 1.2.3 typically occur when visual elements crucial to understanding the video's content are not conveyed through audio.

• Mobile App Example: A cooking app demonstrates a recipe via a video. The video shows the chef adding specific ingredients and performing techniques like "folding the batter." If the audio only describes the cooking steps ("Now add the sugar") but not the visual action of folding, a visually impaired user misses key preparation instructions.
• Web App Example: An e-commerce site features a product showcase video. The video highlights a new feature by visually demonstrating its operation. If the audio track doesn't describe what the feature does or how it works, users who cannot see the demonstration are left uninformed.
• Mobile App Example (Social Media): A user uploads a video of a visual joke or meme. If there's no audio description of the visual elements that make the joke funny, users who are blind will not understand the content.
• Web App Example (News/Information): A news report includes a video segment showing charts or graphs to illustrate data. If the audio doesn't verbally explain the trends or key figures presented in these visuals, users who cannot see the charts miss critical information.
• Mobile App Example (Education): An educational video explains a scientific concept using animated diagrams. If the audio doesn't describe the actions or changes happening in the diagrams, students with visual impairments cannot grasp the concept being taught.

Testing for WCAG 1.2.3 Compliance

#### Manual Testing Steps

1. Identify Video Content: Locate all video elements within your application (mobile or web).
2. Play Videos with Audio Off: Mute your device's audio or your web browser.
3. Observe Visuals: Watch the video carefully. Pay attention to any actions, gestures, on-screen text, or graphical information that is not explicitly described in the audio track.
4. Assess Comprehension: Determine if the visual information conveyed is essential for understanding the video's purpose or narrative.
5. Check for Alternatives: If essential visual information is present, verify if an audio description is provided. This can be through:

• Descriptive Narration: The existing audio track or a separate narration explicitly describes the visual events.
• Media Alternative: A separate, synchronized text description is available.

#### Automated Tools

While direct automated checking for audio description quality is complex and often requires human review, automated tools can identify the *presence* of video content and flag it for manual review.

• Browser Developer Tools: For web applications, browser developer tools can inspect video elements.
• Accessibility Checkers: Tools like axe-core, WAVE, or Lighthouse can identify multimedia elements but typically require manual verification for the audio description itself.

#### Mobile-Specific Considerations

On mobile platforms (Android and iOS), testing involves the same principles but with platform-specific accessibility features:

• Screen Readers (TalkBack/VoiceOver): While screen readers read out on-screen text and UI elements, they do not automatically interpret visual content within videos. You must still manually assess the video's audio track for descriptions.
• Captions vs. Audio Descriptions: Be sure to distinguish between closed captions (which provide spoken dialogue as text) and audio descriptions (which describe visual information). WCAG 1.2.3 requires the latter for visual content.
• App Stores: Ensure that any video content within app store listings also adheres to WCAG 1.2.3.

Fixing WCAG 1.2.3 Violations

The primary fix is to provide an audio description. This can be achieved by:

1. Adding Descriptive Narration:

• For Web: If you control the video production, re-record or edit the audio track to include descriptions of visual actions.
• For Mobile: If using a video playback component, ensure the video asset itself has a descriptive audio track.

1. Providing a Media Alternative:

• For Web: Offer a transcript that includes synchronized descriptions of visual elements. This can be presented as a separate text document or integrated into the page.
• For Mobile: Similar to web, a synchronized transcript can be provided as an accessible document linked from the video player.

Code Example (Conceptual - Web):

While direct code to *add* audio description isn't a simple snippet, here's how you might link to a transcript that serves as a media alternative:

<video controls>
  <source src="your-video.mp4" type="video/mp4">
  Your browser does not support the video tag.
  <a href="transcript-with-descriptions.txt" download>Download Transcript with Audio Descriptions</a>
</video>

In the transcript-with-descriptions.txt file, you would have content like:

[00:00:05] Narrator: The user clicks the 'Add to Cart' button.
[00:00:12] Narrator: A confirmation modal appears on screen, showing the item has been added.

How SUSA Checks for WCAG 1.2.3 Compliance

SUSA (SUSATest) autonomously tests for WCAG 1.2.3 compliance by identifying all video elements within your application during its exploration.

1. Autonomous Video Discovery: SUSA automatically detects video players and embedded videos, whether you upload an APK or provide a web URL.
2. Persona-Based Exploration: SUSA utilizes its 10 user personas, including the curious and novice personas, to interact with and explore video content.
3. WCAG 2.1 AA Testing: As part of its comprehensive WCAG 2.1 AA testing suite, SUSA specifically flags multimedia content that *may* require audio descriptions. While SUSA cannot *hear* the audio or *see* the visuals to determine if a description is sufficient, it identifies the *presence* of video elements that fall under the scope of WCAG 1.2.3.
4. Identifying Missing Alternatives: SUSA's core capability is to find issues. For WCAG 1.2.3, this means it will highlight videos that are present and thus require a human to verify the existence and sufficiency of audio descriptions or media alternatives. This significantly speeds up the QA process by pinpointing areas needing manual accessibility review.
5. Cross-Session Learning: Over time, as SUSA explores your application repeatedly, it learns the structure and content of your app, improving its efficiency in identifying all multimedia elements for review.

By integrating SUSA into your CI/CD pipeline (e.g., via GitHub Actions or its CLI tool pip install susatest-agent), you ensure that potential WCAG 1.2.3 violations are flagged early, preventing costly rework and ensuring a more accessible product for all users.