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

WCAG 1.2.5, Audio Description (Prerecorded), mandates that synchronized media (video) must provide audio descriptions for all visual information that is not conveyed through the main audio track. This

Ensuring WCAG 1.2.5 Compliance: Audio Description for Everyone

WCAG 1.2.5, Audio Description (Prerecorded), mandates that synchronized media (video) must provide audio descriptions for all visual information that is not conveyed through the main audio track. This ensures that individuals who are blind or have low vision can understand the visual content of videos. Think of it as a narrator describing what's happening on screen when no one is speaking.

Why Audio Descriptions Matter

The impact of missing audio descriptions is profound. For a user who is blind, a video without them is essentially an audio-only experience, even if the visual elements are critical to understanding the narrative or information being presented. This exclusion limits their access to educational content, entertainment, news, and essential services.

Consider these user groups:

• Individuals who are blind: They rely entirely on audio cues to comprehend visual information.
• Individuals with low vision: While they may perceive some visual elements, audio descriptions can clarify details they might miss.
• Users in situations where viewing is difficult: This includes multitasking, bright environments, or when the screen is turned off.

Compliance with WCAG 1.2.5 is not just about meeting a standard; it's about building inclusive digital products that serve a broader audience, fulfilling legal requirements like the EU's European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA) in the US.

Common Violations and Examples

Violations of WCAG 1.2.5 occur when visual actions, settings, or character expressions are not described audibly.

Mobile App Examples:

1. On-screen text not read aloud: A crucial alert pops up on screen in a banking app detailing a transaction. Without audio description, a blind user misses this vital information.
2. Visual cues for game progression ignored: In a puzzle game, a character visually points to a specific object on screen to indicate the next step. If this action isn't narrated, the user is stuck.
3. Important gestures or actions not explained: A tutorial video in a photo editing app demonstrates a specific two-finger pinch-to-zoom gesture. If this visual action isn't described, the user won't know how to perform it.

Web App Examples:

1. Key visual information in explainer videos: An e-commerce site uses a video to showcase a product's features. If the video shows a graphic highlighting specific dimensions or material textures without describing them verbally, the information is inaccessible.
2. Changes in UI state not conveyed: A user clicks a button, and a visual animation indicates that an item has been added to their cart. If this visual feedback isn't described, the user might not know if their action was successful.
3. Subtle emotional cues in character interactions: A short film or animated explainer uses facial expressions and body language to convey a character's reaction. Without audio descriptions, the emotional context is lost.

Testing for WCAG 1.2.5 Compliance

Testing for audio description compliance requires a combination of manual review and automated checks.

#### Manual Testing Steps

1. Play the video with the sound off: This simulates the experience of a user who is blind. Pay close attention to any visual information that seems critical for understanding the content but is not conveyed through dialogue or existing sound effects.
2. Listen for narration: As you play the video normally, actively listen for descriptions of visual elements. Does the narration cover actions, character expressions, on-screen text, and other visual cues?
3. Compare visual and audio: If you can see, compare the visual content with the audio track. Are there significant visual events or details that are not mentioned in the audio?
4. Test with assistive technology (optional but recommended): Use a screen reader with the video player to see how it handles the media. While screen readers don't inherently "hear" audio descriptions, their behavior can sometimes highlight missing information if the player itself doesn't provide alternative text for visual elements.

#### Automated Tools

While manual testing is crucial for nuanced understanding, automated tools can flag potential issues:

• SUSA Autonomous Exploration: SUSA can identify issues related to media playback and discover scenarios where visual information might be critical but not communicated through audio.
• Specialized Accessibility Checkers: Tools like WAVE (for web) or platform-specific accessibility scanners can sometimes flag media elements that lack descriptive alternatives, though their ability to *verify* the *quality* of audio descriptions is limited. They are better at identifying the *absence* of a descriptive track.

#### Mobile-Specific Considerations

• Video Player Implementation: Ensure the native video player or any third-party player used in your mobile app supports accessibility features. This includes providing mechanisms for users to enable or disable audio descriptions if they are available.
• Dynamic Content: If your app displays video content dynamically based on user interaction or data, ensure that audio descriptions are available for all relevant visual information within those videos.
• Platform Guidelines: Adhere to Apple's Human Interface Guidelines and Android's Material Design guidelines regarding media accessibility.

Fixing Violations

Implementing audio descriptions involves creating a separate audio track that describes the visual content.

For Web Applications:

• HTML5 tag: If you are using the HTML5 video element, you can include a separate audio track using the element with the kind="descriptions" attribute.

    <video controls>
      <source src="my_video.mp4" type="video/mp4">
      <track kind="captions" srclang="en" label="English Captions" src="captions.vtt">
      <track kind="descriptions" srclang="en" label="English Audio Description" src="descriptions.vtt">
    </video>

The descriptions.vtt file would contain time-coded descriptions.

• Video Editing Software: Use professional video editing software (e.g., Adobe Premiere Pro, Final Cut Pro) to record and edit the audio description track. This track is then mixed with the video.

For Mobile Applications:

• Native Player APIs: iOS and Android provide APIs for managing audio tracks within their respective media players. You'll need to ensure your video playback implementation correctly handles and exposes a separate audio description track.
• Third-Party SDKs: If using a third-party video player SDK, consult its documentation for supporting multiple audio tracks, including audio descriptions.
• Server-Side Encoding: Often, the video file itself will contain multiple audio tracks, including the primary audio and the audio description track. The player then selects the appropriate track based on user settings or system preferences.

How SUSA Checks for WCAG 1.2.5

SUSA tackles WCAG 1.2.5 through its autonomous exploration capabilities, augmented by persona-based testing.

• Autonomous Exploration: When SUSA encounters video content, it will attempt to interact with it. During this exploration, it can identify if a video is playing and if there are any associated media controls. While SUSA doesn't "listen" to audio descriptions directly, its exploration can uncover scenarios where visual information is presented without accompanying narration.
• Persona-Based Dynamic Testing: SUSA utilizes 10 distinct user personas, including an accessibility persona. This persona is specifically configured to probe for accessibility violations. When exploring video content, the accessibility persona can trigger checks for the presence of alternative media tracks or identify if critical visual information is likely missing from the audio.
• Flow Tracking: For common user flows that might involve video tutorials or product demonstrations (e.g., registration, checkout), SUSA can track the success or failure of these flows. If a user (simulated by SUSA) gets stuck or fails a flow due to missing visual information in a video, SUSA flags this as a potential accessibility issue, which could include a lack of audio description.
• Cross-Session Learning: With each run, SUSA gets smarter about your application. If it repeatedly encounters video content that appears to lack descriptive audio during its explorations, it will continue to flag these areas for review, increasing the likelihood of identifying WCAG 1.2.5 violations over time.

By uploading your APK or web URL to SUSA, you initiate an autonomous exploration that discovers not only functional bugs and UX friction but also critical accessibility barriers like missing audio descriptions, helping you build more inclusive applications.