Testing Video, Audio and Time Limits

Media and timing accessibility testing checks whether people who cannot hear the sound, cannot see the picture or need more time can still use audio, video and anything with a clock. WCAG 2.2 covers media under guideline 1.2 Time-based Media: captions carry the speech and the important sounds for deaf and hard-of-hearing users, audio description tells blind users what is only shown on screen, and a transcript gives everyone a text version to read at their own pace.

Timing rules sit next to them: audio that starts by itself must be stoppable (1.4.2), time limits must be adjustable (2.2.1), and moving or auto-updating content must be possible to pause (2.2.2). For example, a training video that starts talking on page load with no way to stop it, with automatic captions that turn "15 minutes" into "50 minutes", on a page that logs the learner out mid-video without warning, fails at least three criteria (1.4.2, 1.2.2, 2.2.1) before the learner has pressed anything.

Why it matters

When media or timing has a defect, content is not just harder to use, it is unavailable: a deaf learner cannot follow an uncaptioned lesson, a blind user misses the steps a demo only shows, a screen-reader user cannot hear their screen reader over audio that started on its own, and someone who types slowly with a switch device or a screen reader loses a half-finished form when the session expires. For a product this means support calls, lost sales and, where accessibility is required by law or contract, a compliance gap.

Most of these defects are also invisible to automated checkers. A scanner can see that a <track> element exists, but not whether the captions match the speech, name the speakers or keep pace with the video, and it will not wait 15 minutes for a session warning. This is manual work, and a tester who knows the criteria can raise most of it while the video is still a script.

Which media criteria apply: 1.2.1 to 1.2.5

Start by classifying each piece of media, because the criteria depend on what it contains and whether it is live. WCAG calls sound and moving pictures together synchronized media; a podcast is audio-only and a silent product animation is video-only.

Three alternatives appear in the criteria. Captions are synchronized text for the speech and for the non-speech sounds needed to understand the content, such as a doorbell, laughter or music, with the speaker identified; that is what separates them from dialogue-only subtitles, although some countries call both subtitles. Audio description is narration added to the soundtrack that describes important visual information the soundtrack does not already convey. An alternative for time-based media, called a full text alternative in this lesson, describes what is seen and heard in the correct order; a transcript with visual descriptions is the common form. It is not the same as the short text alternative (alt text) of an image.

  • 1.2.1 Audio-only and Video-only (Prerecorded), Level A: a transcript for prerecorded audio; a full text alternative or an audio track with the same information for prerecorded silent video.
  • 1.2.2 Captions (Prerecorded), A: captions for all prerecorded audio in synchronized media.
  • 1.2.3 Audio Description or Media Alternative (Prerecorded), A: audio description of the video, or a full text alternative.
  • 1.2.4 Captions (Live), AA: captions for live audio in synchronized media, such as a webinar or a live stream.
  • 1.2.5 Audio Description (Prerecorded), AA: audio description is required; the text alternative that was enough for 1.2.3 no longer suffices. Where everything shown is already said in the audio, no description is needed.
  • 1.2.1 to 1.2.3 exempt a media version of text that is already on the page when it is clearly labelled as such. Level AAA adds sign language, extended audio description, a full media alternative and live audio-only alternatives (1.2.6 to 1.2.9).
WCAG media criteria: prerecorded audio-only or video-only needs an equivalent alternative (1.2.1), live video captions (1.2.4), prerecorded video captions (1.2.2), plus audio description if the picture shows more than the sound (1.2.5).
Question 1: What does the media contain?
  • Answer: Sound only, prerecorded: a podcast

    Outcome: A transcript1.2.1, Level A
  • Answer: Moving pictures only, prerecorded: a silent demo

    Outcome: A full text alternative, or an audio track with the same information1.2.1, Level A
  • Answer: Sound and moving pictures: synchronized media

    Question 2: Is it live?
    • Answer: Yes: a webinar or a live stream

      Outcome: Live captions1.2.4, Level AA
    • Answer: No: prerecorded

      Question 3: Does the picture show important information that the sound does not convey?On-screen steps, text, charts
      • Answer: No: the narration says it all

        Outcome: Captions only1.2.2, Level A; no audio description needed
      • Answer: Yes

        Outcome: Captions and audio description1.2.2 (A) and 1.2.5 (AA); a full text alternative is enough only for 1.2.3 (A)

Levels A and AA only. 1.2.1 to 1.2.3 do not apply to a media version of text already on the page that is clearly labelled as such.

Testing caption and transcript quality

WCAG requires captions but sets no numeric accuracy target, so the expected result comes from the source: the script, or a careful listen. Watch the whole video with sound and captions on. Treat automatic captions as an unreviewed draft: they often mishear names, product terms and numbers, and rarely identify speakers or sounds. Captions usually come as a WebVTT file (.vtt), the format browsers load through the HTML <track> element: in it the <v> tag names the speaker, and by convention a sound is written in square brackets.

  • Synchronization: each caption appears with its speech and leaves when the speaker stops. Check the start, the middle and the end, because a file timed for a different edit drifts away from the audio.
  • Accuracy: words, names and numbers match the audio. Paste the script and the caption text, without the timing lines, into a text diff in word mode to see every difference at once.
  • Speakers: when more than one person talks, or the speaker is off screen, the caption says who is speaking.
  • Sound cues: meaningful sounds appear in square brackets, such as [alarm beeping] or [music stops].
  • Arabic captions: lines read right to left. The browser takes each caption line's direction from its first strong character, the first letter with a fixed direction (Arabic or Latin; digits and punctuation do not count). A line that starts with a Latin brand name or an English term is therefore laid out left to right, with its full stop at the right end. Test such lines on purpose (a right-to-left mark, U+200F, at the start of the line fixes them), and check that the track is marked srclang="ar" and has a readable label in the captions menu.
  • Transcripts: a link next to the player, and the full text with speaker names, sound cues and, for video, a description of what is shown.
WEBVTT

00:00:01.000 --> 00:00:04.200
<v Trainer>Open Orders and filter by status.

00:00:04.200 --> 00:00:05.500
[notification chime]

00:00:05.500 --> 00:00:09.000
<v Customer>Why is my order still pending?

00:00:09.000 --> 00:00:12.800
<v Trainer>Pending means the payment
has not been confirmed yet.

Try it: Text Diff Try it: Arabic Test Data Generator

Autoplay and the media player

1.4.2 Audio Control (A): if any audio on a page plays automatically for more than 3 seconds, there must be a way to pause or stop it, or to set its volume independently of the system volume. WCAG lists it among the criteria that apply to all content on a page, because a failure interferes with using anything else there. Browsers block some autoplay with sound, but their rules differ and they usually allow sound once the user has interacted with the site, so test with sound autoplay allowed in the browser's site settings, and again by opening the page after you have clicked elsewhere on the site.

The player itself must work without a mouse and make sense to a screen reader. The keyboard accessibility guide covers the method; for a player, check these points:

  • Every control is reachable with Tab in a logical order, works with Enter or Space, and shows visible focus against the dark video (2.1.1, 2.4.3, 2.4.7).
  • Seek and volume sliders move with the arrow keys and announce a useful value, such as "1 minute 20 seconds of 4 minutes", not "0.33".
  • Buttons have names and states that update: Play becomes Pause, and Captions is announced as on or off (4.1.2).
  • Focus can leave an embedded player, including a third-party iframe, with Tab and Shift+Tab, or with another key the page tells the user about (2.1.2 No Keyboard Trap), and Escape leaves full screen.
  • Single-key shortcuts such as K or M work only while the player has focus, or can be turned off, or remapped to a combination with Ctrl or Alt (2.1.4 Character Key Shortcuts).
An accessible video player has reviewed captions, an audio description button, a transcript link and eight Tab stops in order; the defective one has a Play control Tab skips and a captions button with no name. Conceptual model

Player that passesPass

Every control is a Tab stop, in reading order.

Video picture
Caption line with the speaker named
Focus order 1: Play and Pause buttonFocus order 2: Seek slider: arrow keys, value in minutes and secondsFocus order 3: Mute buttonFocus order 4: Volume slider: arrow keysFocus order 5: Captions button, announced on or offFocus order 6: Audio description buttonFocus order 7: Full screen button
Focus order 8: Transcript link under the player
Captions:
Reviewed: in sync, speakers named, sound cuesPass
Audio description:
A button switches to the described versionPass
Keyboard:
Eight Tab stops in order; sliders move with the arrow keysPass
Screen reader:
Play becomes Pause; Captions announced on or offPass

Player with typical defectsFail

The Play control has no number because Tab skips it.

Video picture
Automatic captions, not reviewed, no speaker names
Play control built from a div: Tab skips itFocus order 1: Seek sliderFocus order 2: Mute buttonFocus order 3: Volume slider: ignores the arrow keysFocus order 4: Captions button with no nameFocus order 5: Full screen button
Captions:
Automatic, not reviewed: 1.2.2Fail
Audio description:
None and no transcript, although the video shows steps nobody says aloud: 1.2.3, 1.2.5Fail
Keyboard:
Play skipped; volume ignores the arrow keys: 2.1.1Fail
Screen reader:
Captions button announced only as “button”: 4.1.2Fail

Illustrative player in a left-to-right page. Numbers are Tab stops; marked blocks are defects.

Time limits, session time-outs and carousels

2.2.1 Timing Adjustable (A) applies to each time limit the content sets: a session that ends after inactivity, a timed offer that holds a price or seats for 10 minutes, a form that must be finished in time. At least one option must hold: the user can turn the limit off beforehand; adjust it to at least ten times the default; or is warned before it expires, gets at least 20 seconds to extend it with a simple action such as pressing one key, and can extend it at least ten times. The exceptions are real-time events such as an auction where no alternative to the limit is possible, limits where more time would invalidate the activity (essential), and limits longer than 20 hours.

To test a 15-minute session without waiting, ask the developers to shorten it in the test environment. Then check that the warning appears in time, is announced by a screen reader, can be reached at once from the keyboard, and that extending really renews the server session, not only the visible counter. After expiry, 2.2.5 Re-authenticating (AAA) asks that the user can sign in again and continue without losing data; many teams treat that as good practice.

2.2.2 Pause, Stop, Hide (A), introduced in the visual accessibility guide for motion, also covers auto-updating content. Moving, blinking or scrolling content that starts automatically, lasts more than five seconds and sits beside other content needs a way to pause, stop or hide it; content that updates by itself, such as a news ticker or live scores, needs a way to pause, stop or hide it or to control how often it updates. Both parts make an exception for movement or updating that is essential to the activity.

  • Carousel: a pause or stop control that works with the keyboard (2.2.2). The ARIA Authoring Practices carousel pattern places it first in the Tab order inside the carousel, before the rotating slides.
  • Rotation stops when keyboard focus enters the carousel, and also while the mouse hovers over it, as the same pattern describes; stopping on hover alone is not enough, because keyboard and touch users cannot hover.
  • Once stopped by focus or by the pause control, the carousel stays stopped until the user starts it again.

Worked example: a course page checklist and its defects

A training platform's course page has an English intro video with English and Arabic captions, a podcast episode, a background video in the page header, a promo carousel and a 15-minute session time-out. The intro video's presenter says aloud everything shown on screen, so it needs captions but no audio description. The tester first lists every media item and every time limit, then runs the checklist at the end of this section with the keyboard, a screen reader and the sound on, in both languages.

The defects found, written as bug titles with the criterion:

  • “Header background video plays music with sound on load and has no controls at all” (1.4.2, 2.2.2)
  • “Intro video: automatic English captions not reviewed; at 02:14 ‘fifteen minutes’ is captioned ‘fifty minutes’” (1.2.2)
  • “Arabic captions: lines that start with the brand name are laid out left to right, with the full stop at the right end” (Arabic caption quality)
  • “Podcast episode 7 has no transcript” (1.2.1)
  • “Captions button is announced only as ‘button’, with no name and no on/off state” (4.1.2)
  • “Session ends after 15 minutes idle with no warning; the half-written assignment is lost” (2.2.1)
  • “Promo carousel advances every 4 seconds with no pause control and keeps rotating while focus is inside” (2.2.2)
MEDIA AND TIMING CHECKLIST: course page, build 4.12, en + ar

Inventory
[ ] Every media item classified: audio-only, video-only or synchronized; live or not
[ ] Every time limit listed: session, holds, countdowns, auto-advancing content
Prerecorded media
[ ] Audio-only: transcript linked next to the player (1.2.1)
[ ] Captions: in sync, accurate, speakers named, sound cues, to the end (1.2.2)
[ ] Visual-only information: audio description, or not needed (1.2.3, 1.2.5)
[ ] Arabic captions: right-to-left lines, Latin words and digits in order
Live media
[ ] Live sessions have captions (1.2.4)
Player
[ ] No sound over 3 s on load without pause, stop or volume control (1.4.2)
[ ] Tab, Enter/Space, arrows on sliders, visible focus (2.1.1, 2.4.7)
[ ] Names and states: Play/Pause, Captions on/off (4.1.2)
[ ] No trap in an embedded player; letter shortcuts only on focus (2.1.2, 2.1.4)
Timing
[ ] Each time limit can be turned off, adjusted (x10) or extended (2.2.1)
[ ] Extend: warning first, >= 20 s, one simple action, at least 10 times
[ ] Carousels, tickers: pause control (2.2.2); placed first, stops on focus (APG)

Try it: Test Case Generator Try it: AI QA Checklist Generator

Common mistakes

  • Accepting automatic captions without review: they mishear names, terms and numbers and rarely name speakers or describe sounds.
  • Checking only that a captions button exists, instead of watching the video to the end with sound and captions on.
  • Asking for captions but forgetting audio description when the video shows information nobody says aloud, such as on-screen steps, text or charts.
  • Testing autoplay in a browser that blocks it, and passing a page that plays sound for users whose browser allows it.
  • Never testing the session time-out because it takes too long, instead of asking for a short time-out in the test environment.
  • Accepting pause-on-hover as the only way to stop a carousel; keyboard and touch users cannot hover.

The QA perspective

Media accessibility is cheapest before the video exists. When media is planned, ask for the script and ask: will the narration describe what is shown (which can make separate audio description unnecessary)? Who writes and reviews the captions in each language? Who provides captions for live sessions? Propose "captions reviewed, transcript published" as part of the definition of done for media content.

Time limits need a decision as well as a test. Ask the product owner and the security team which limits exist, which 2.2.1 option each one uses, and whether any claims an exception; record the answers in the test basis. In defect reports give the media timestamp of a bad caption, the browser, player and assistive technology used, the configured time-out, and a short screen recording: a caption defect without a timestamp is hard to find again.

Practice exercise

Review a webinar page for media and timing

Your task

A team has published the recording of a webinar together with the registration form for the next live session. The material below lists what the page contains and what you observed while testing it.

For each item, decide which WCAG 2.2 Level A and AA criteria apply, judge whether the observation passes or fails, and write every failure as a bug title with the criterion number. Note the questions you would ask the team.

Material
Webinar page: "Testing in CI" (English, recorded, 45 min)
1. Recording: two speakers. Slide 9 shows a pricing table that nobody
   reads out. Captions: English only, automatic, not reviewed.
   At 12:40 "fifteen" is captioned "fifty". Speakers are never named.
2. "Listen on the go": an audio-only version. No transcript.
3. On load the recording plays with sound. The player's Pause button
   is the first Tab stop and works with Enter.
4. Player: the volume slider ignores the arrow keys.
5. Next live webinar: registration form with a 10-minute countdown;
   at 0:00 the form clears. No warning, no way to extend.
6. Sidebar: an "Upcoming events" ticker scrolls all the time.
Steps
  1. Classify each media item: audio-only, video-only or synchronized; live or prerecorded.
  2. List the criteria that apply to each item and to each time limit or moving element.
  3. Compare each observation with its criterion and decide pass or fail.
  4. Write each failure as a bug title with the criterion, then list your questions.
Show the model answer
Model answer

Recording (prerecorded synchronized media): 1.2.2, plus 1.2.3 and 1.2.5 because slide 9 shows information the audio does not convey. Defects: “Automatic captions not reviewed: ‘fifteen’ captioned as ‘fifty’ at 12:40” (1.2.2); “Captions never identify which of the two speakers is talking” (1.2.2); “Pricing table on slide 9 has no audio description and no full text alternative” (1.2.3, 1.2.5). English-only captions are not a 1.2.2 failure for an English recording; Arabic subtitles would be a localisation requirement.

Audio-only version: 1.2.1. Defect: “Audio-only version of the webinar has no transcript” (1.2.1).

Autoplay: 1.4.2 passes, because a keyboard user reaches a working Pause button at the first Tab stop; the same button also meets 2.2.2 for the moving picture. Still suggest not autoplaying, since a screen-reader user hears the recording over their screen reader until they find it.

Player: 2.1.1. Defect: “Volume slider cannot be adjusted with the arrow keys” (2.1.1).

Registration countdown: 2.2.1. Defect: “Registration form clears after 10 minutes with no warning and no way to extend” (2.2.1). Ticker: 2.2.2. Defect: “Upcoming events ticker scrolls continuously with no pause, stop or hide control” (2.2.2).

Questions: why does registration need a time limit at all? Who will provide live captions for the next webinar (1.2.4)? Who reviews captions before they are published?

Frequently asked questions

Are subtitles the same as captions?

Not quite. Subtitles usually carry only the dialogue, often translated for people who can hear. Captions also identify speakers and include the non-speech sounds needed to understand the content, which is what deaf and hard-of-hearing viewers need. Some countries use the word subtitles for both, so check the content, not the label in the menu.

Do automatic captions meet 1.2.2?

Only once they are accurate. Treat them as a first draft: someone must review and correct words, names, numbers, speaker identification and sound cues. Test unreviewed automatic captions like any other content; errors that change the meaning are defects.

Does every video need audio description?

No. Audio description is needed for important visual information that the soundtrack does not already convey. If the narration already says everything shown, such as "click Save at the top right", no separate description is needed. At Level A a full text alternative can stand in for description (1.2.3); at Level AA, 1.2.5 requires audio description for prerecorded video.

Is a session time-out a security requirement that overrides 2.2.1?

No. Understanding WCAG 2.2 counts a time limit added for security as one set by the content, so 2.2.1 applies to it. In most cases both can be met: keep the time-out, but warn the user before it ends, give at least 20 seconds to respond, and let them extend it with one simple action at least ten times. If the business claims an exception, such as an essential time limit, ask for it to be documented and reviewed.

References

  • Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
  • Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).
  • ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)Patterns for common widgets (tabs, menus, dialogs, comboboxes) with the expected keyboard interaction and ARIA usage — the reference testers compare custom components against.
  • HTML Living StandardWHATWGThe HTML language, including named character references (entities) and the parsing rules browsers follow.

Practise with Mutqan tools

Compare two texts line by line or word by word and highlight differences.

Formatting

Generate Arabic names, addresses, sentences, numbers (Arabic-Indic digits) and RTL edge cases for localisation testing.

Test Data

Generate structured test cases (id, title, preconditions, steps, expected result, priority) from a feature description and field list.

Test Design

Generate a tailored QA checklist (functional, UI, API, security, performance, accessibility, release) for any feature with Mutqan AI.

Test Generation AI

Go deeper

Your progress on this topic

Part of the QA Roadmap