WCAG 1.2.1 Audio-only and Video-only — Testing Guide for Mobile & Web Apps

WCAG 1.2.1, at Level A, mandates that all pre-recorded audio-only and video-only content must have a text alternative. This means that if your application presents audio without visuals, or visuals wi

Ensuring WCAG 1.2.1 Compliance: Audio-Only and Video-Only Content

WCAG 1.2.1, at Level A, mandates that all pre-recorded audio-only and video-only content must have a text alternative. This means that if your application presents audio without visuals, or visuals without audio, users who cannot perceive that content must still be able to understand its meaning.

What WCAG 1.2.1 Requires (in plain English)

Essentially, if you have content that relies solely on sound or sight, you must provide a text equivalent. For audio-only content (like a podcast snippet), this means providing a transcript. For video-only content (like a silent film clip), it means providing a text description of the visual information. This ensures that users with visual or auditory impairments can access the same information as users without these disabilities.

Why WCAG 1.2.1 Matters: Real User Impact

This criterion directly impacts a significant user base:

• Users who are blind or have low vision: They cannot perceive visual information in video-only content. A text description allows them to understand what is happening.
• Users who are deaf or hard of hearing: They cannot perceive audio information in audio-only content. A transcript provides the spoken information.
• Users in noisy environments: They might miss crucial audio cues in video-only content.
• Users with cognitive disabilities: Text alternatives can sometimes aid comprehension even for users without specific sensory impairments.
• Search engines and indexing: Text content is indexable, making your audio and video content discoverable by search engines.

Compliance with WCAG 1.2.1 is not just a matter of meeting standards; it's about building inclusive applications that cater to diverse user needs. In regions like the EU, accessibility laws like the European Accessibility Act (EAA) and in the US, the Americans with Disabilities Act (ADA), increasingly mandate such compliance for digital services.

Common Violations with Examples

Mobile Apps:

1. Audio-only promotional message: An app plays a short audio advertisement for a new feature upon launch, but provides no accompanying text or visual indicator of what is being said.
2. Video-only tutorial snippet: A mobile app uses a short, silent animated video to demonstrate a complex gesture, without any captions or descriptive text explaining the animation.

Web Applications:

1. Podcast playback without transcript: A news website embeds a pre-recorded audio interview, but only offers the audio player, neglecting to provide a downloadable or viewable transcript.
2. Silent product demonstration video: An e-commerce site features a product video that relies on visual cues and on-screen text graphics to explain features, but has no audio narration and no accompanying text description.
3. Audio-only user guide: A help section of a web application offers audio recordings of common troubleshooting steps without any associated text.

How to Test for Compliance

Manual Testing Steps:

1. Identify all audio-only and video-only content: Audit your application for any media elements that lack a corresponding sensory counterpart. This includes embedded audio players and video players with no sound or no visuals.
2. Check for text alternatives:

• For audio-only content, look for a transcript. This could be a link to a separate text file, a visible text block on the same page, or integrated captions that are presented as text.
• For video-only content, look for a descriptive text alternative. This could be an alt attribute on an tag if the video is presented as an image, or a descriptive text accompanying the video.

1. Verify transcript/description accuracy: Read the transcript or description. Does it accurately convey the information presented in the audio or video?
2. Test with assistive technologies:

• Screen Readers (e.g., VoiceOver on iOS, TalkBack on Android, NVDA/JAWS on web): Navigate to the content. Does the screen reader announce the availability of a transcript or description? Can the user access it easily?
• Magnification tools: While less relevant for this specific criterion, ensure that any accompanying text is resizable and readable.

Automated Tools:

While 100% automated detection of the *accuracy* of transcripts and descriptions is challenging, automated tools can identify the *presence* of media and flag potential issues.

• Accessibility Checkers (Browser Extensions/Online Tools): Tools like axe DevTools, WAVE, and Lighthouse can flag missing alt text for images (which might be used for video-only content) and can sometimes identify media elements that might require attention.
• Static Analysis Tools: Some linters and code analysis tools can be configured to check for common accessibility anti-patterns.

Mobile-Specific Considerations:

• Android: Use adb commands or Android Studio's accessibility scanner to identify potential issues. Test with TalkBack enabled.
• iOS: Use Xcode's accessibility inspector and test with VoiceOver enabled.
• App Automation Frameworks: Tools like Appium can be used to programmatically interact with elements and check for the presence of text alternatives.

How to Fix Violations

For Audio-Only Content (e.g., a podcast episode):

Provide a transcript. This can be implemented as:

• A separate HTML page: Link to a dedicated page containing the full transcript.

    <audio controls>
      <source src="podcast.mp3" type="audio/mpeg">
      Your browser does not support the audio element.
      <a href="podcast_transcript.html">Transcript of Podcast</a>
    </audio>

• Inline text: Display the transcript directly below or beside the audio player.

    <audio controls>
      <source src="podcast.mp3" type="audio/mpeg">
      Your browser does not support the audio element.
    </audio>
    <p><strong>Transcript:</strong> [Full transcript text here...]</p>

• Captions: While often associated with video, captions can also be used for audio-only content, especially if the audio is part of a larger visual interface.

For Video-Only Content (e.g., a silent animation):

Provide a descriptive text alternative.

• Using alt text for an image representing the video: If the video is presented as a static image initially, use descriptive alt text.

    <img src="animation_thumbnail.png" alt="Animation showing users how to swipe left to dismiss notifications.">

• Descriptive text alongside the video:

    <video controls>
      <source src="silent_tutorial.mp4" type="video/mp4">
      Your browser does not support the video element.
    </video>
    <p>This animation demonstrates the correct technique for dismissing notifications by swiping left on the notification card.</p>

• Descriptive text within the video's context: Ensure the surrounding text or interface elements adequately describe the video's content if the video itself is purely visual.

How SUSA Checks for WCAG 1.2.1 Compliance

SUSA's autonomous QA platform efficiently addresses WCAG 1.2.1 by integrating this check into its exploration process.

• Autonomous Exploration: When you upload an APK or provide a web URL, SUSA navigates your application autonomously. It identifies all media elements, including audio and video players.
• Persona-Based Testing: SUSA utilizes its 10 distinct user personas, including the novice, elderly, and accessibility personas. These personas simulate users who may rely on text alternatives to understand content.
• Content Analysis: During exploration, SUSA analyzes the context of media elements. It looks for associated text tracks, transcripts, or descriptive content.
• Identifying Missing Alternatives: If SUSA encounters an audio-only or video-only media element without a discernible text alternative (e.g., a transcript link, descriptive text nearby), it flags this as a potential WCAG 1.2.1 violation.
• Accessibility Violation Reporting: SUSA categorizes these findings under accessibility violations, providing specific details about the element and the missing text alternative. This allows developers to quickly pinpoint and rectify issues.
• Cross-Session Learning: With each run, SUSA's understanding of your application deepens, improving its ability to identify and report on accessibility issues, including those related to WCAG 1.2.1.

By leveraging SUSA, you can proactively identify and resolve WCAG 1.2.1 compliance gaps, ensuring your application is accessible to a broader audience without requiring manual, script-heavy testing for this specific criterion.