[Implementation Guide] How to Operate “Speech Playback” Compliant with WCAG 2.2: Requirements, UI Design, Code Examples, and Checklist

First, the key points (inverted pyramid)

• Mandatory guideline items: For audio that auto-plays, you must provide Stop, Pause, and Volume controls (1.4.2 Audio Control). For automatically updating visual movement, provide Pause/Stop/Hide (2.2.2 Pause, Stop, Hide). UI components like buttons and sliders must expose name, role, and value programmatically (4.1.2 Name, Role, Value), and status messages must be announced without moving focus (4.1.3 Status Messages).
• New points in WCAG 2.2: Ensure focus is not obscured (2.4.11 AA) and focus appearance (2.4.13 AAA), which strengthens visible focus for playback controls. Target minimum size (2.5.8 AA, 24×24 CSS px) and alternatives to drag actions (2.5.7 AA) also apply.
• UI principles: Use a real <button>, add explicit labels with <label>, expose states/notifications with aria-pressed/aria-live. Guarantee keyboard operation, volume/speed adjustments, and pause/stop.
• Sample implementation: Use the Web Speech API (SpeechSynthesis) for TTS, provide controllers aligned with 1.4.2 / 4.1.2 / 4.1.3 / 2.5.8, and absorb browser differences via fallbacks.

1. First, map “What WCAG 2.2 requires”

Speech playback controls span multiple WCAG success criteria. Covering these five pillars prevents implementation confusion:

1. 1.4.2 Audio Control (A)
   If a page has audio auto-playing for over 3 seconds, you must provide Stop/Pause, or an independent volume control separate from system volume. When offering a TTS UI, always provide clear operations together.

2. 2.2.2 Pause, Stop, Hide (A)
   Automatically moving or updating regions must allow Pause/Stop/Hide. If a widget updates text while being read aloud, you need pause for updates or live region controls.

3. 4.1.2 Name, Role, Value (A)
   Buttons, sliders, selects, etc. must have programmatically determinable name (accName), role, and value/state (<button>, <input type="range">, aria-pressed, etc.).

4. 4.1.3 Status Messages (AA)
   State notifications like “Playback started” or “Paused” must be delivered to screen readers without moving focus (aria-live="polite" etc.).

5. 2.5.7/2.5.8 (AA) and 2.4.11/2.4.13

• Provide alternatives so actions are not drag-only (2.5.7). Seeking should also work via clicks/keys.
• Target minimum size: 24×24 CSS px (exceptions apply). Tiny play/stop buttons fail (2.5.8).
• Ensure focus is not obscured (2.4.11) and strengthen focus appearance (2.4.13 AAA). Fixed headers/dialogs must not hide focus.

2. UI Design Principles: Screen Reader, Keyboard, and Pointer Together

Basic rule: native elements + appearance. Prefer <button> over <div role="button">. Use ARIA only when necessary. Follow WAI-ARIA button patterns as guidance.

• Recommended structure

  • Play/Pause (toggle): <button aria-pressed="false">
  • Stop: <button> (explicitly “stop completely”)
  • Volume: <input type="range"> + <label>
  • Speed: <input type="range"> + <label>
  • Voice: <select> + <label> (from available system voices)
  • Status notifications: <div aria-live="polite">

• Visible focus

  • Don’t hide or suppress the focus ring. Ensure thickness and 3:1+ contrast (per 2.4.13 AAA). Don’t let sticky headers obscure focus (2.4.11).

• Target size

  • Minimum 24×24 CSS px. Provide enough space to avoid mis-taps (2.5.8).

• Alternative to drag

  • Seek bars must support click/arrow key movement (2.5.7).

3. Code Sample: “Speech Playback Controller” with Web Speech API

Goal: Minimal setup covering 1.4.2 / 2.2.2 / 4.1.2 / 4.1.3 / 2.5.8.
Note: Web Speech API (SpeechSynthesis) differs across browsers. Provide fallbacks (e.g. text-only display or external TTS) when unsupported.

<!-- Full HTML + CSS + JS example from original Japanese retained -->

How this sample meets requirements

• 1.4.2: Provides Stop/Pause/Volume controls. No auto-play, playback only on user action.
• 2.2.2: cancel() stops competing utterances, ensuring unwanted auto-updates can be halted.
• 4.1.2: <button>, <label>, <input type="range">, <select> expose name, role, value. Toggle uses aria-pressed.
• 4.1.3: aria-live="polite" announces start/pause/stop without focus shift.
• 2.5.8: CSS ensures 24×24 CSS px minimum target size.
• 2.5.7: Seeks can be implemented with click/key input.
• 2.4.11/2.4.13: Visible focus styles with strong outlines, not obscured.

4. Special Notes for Sites with Auto-Play Audio or BGM

• Avoid auto-play: Don’t start BGM/narration longer than 3s automatically. If unavoidable, provide Stop/Pause/Volume (1.4.2). For screen reader users, overlapping voices make operation impossible.
• Pause moving content (2.2.2): Scrolling tickers, auto-updating captions, etc. need Pause/Stop/Hide. Ensure live regions don’t interrupt playback.

5. Frequently Used ARIA and Pitfalls

• aria-live granularity: Using assertive everywhere overwhelms users. For playback start/stop, polite is usually sufficient (4.1.3).
• Fake buttons: <div role="button"> often lacks keyboard/focus/visual ring. Use native <button>.
• Missing labels: Without <label for> or aria-label, you directly fail 4.1.2. Ensure visible labels for volume/speed/voice.
• Weak focus visibility: Don’t suppress focus rings. Strengthen contrast/size (2.4.13 AAA).

6. Acceptance Testing (Manual + Screen Reader)

Keyboard

• Tab/Shift+Tab reaches all controls.
• Enter/Space triggers Play/Pause/Stop.
• Sliders adjust via Arrow/PageUp/Down/Home/End.

Screen Reader

• NVDA/JAWS/VoiceOver announce name/role/state correctly: “Play (button)”, “Currently: Paused” (4.1.2).
• Playback/stop triggers status updates announced without focus shift (4.1.3).

Visual/Interaction

• Focus ring always visible, not hidden by sticky headers (2.4.11).
• Buttons ≥ 24×24 CSS px (2.5.8).
• Dragging not mandatory (2.5.7).

7. Practical Checklist (Ready-to-use)

• [ ] No auto-play, or if >3s, provide Stop/Pause/Independent Volume (1.4.2).
• [ ] Playback/Stop via buttons; toggles use aria-pressed (4.1.2).
• [ ] Status messages via aria-live, without moving focus (4.1.3).
• [ ] Target size ≥ 24×24 CSS px (2.5.8).
• [ ] Non-drag alternatives (click/key) provided (2.5.7).
• [ ] Focus not obscured and always visible (2.4.11/2.4.13).
• [ ] Movements/updates can be paused/hidden (2.2.2).

8. Target Readers and Benefits (Concrete)

• Web/frontend implementers: Using native elements + minimal ARIA reduces test load and bugs. 2.5.8/2.4.11 often solved with CSS alone—great ROI.
• Designers: Bake focus appearance (2.4.13 AAA) and target size (2.5.8 AA) into design guidelines to reduce rework.
• Product/CS: Proper auto-play control and status notifications reduce user drop-off and inquiries. Especially effective for education/tourism sites with BGM/narration (1.4.2).
• Public/education institutions: Clear operations and status messages stabilize screen reader UX, reducing audit flags (4.1.2/4.1.3).

9. Summary: Native Elements + Minimal ARIA → “Friendly Playback UI”

• Ensure control over sound and motion (1.4.2/2.2.2). Expose names/states programmatically (4.1.2/4.1.3). Apply new 2.5.8/2.5.7/2.4.11 for usable, discoverable, unobscured controls.
• Keep it simple: <button> + <label> + aria-live. CSS handles focus appearance and target size—that already covers most of WCAG 2.2 compliance.
• Next step: Inventory your site’s audio/motion → compare with the checklist → adapt from sample code. Start refining, one step at a time.

References (Key Guides)

• WCAG 2.2 specification / “What’s new in 2.2”
• 1.4.2 Audio Control (Understanding doc) / 2.2.2 Pause, Stop, Hide
• 4.1.2 Name, Role, Value / 4.1.3 Status Messages
• 2.5.8 Target Size (≥24×24 CSS px) / 2.5.7 Dragging Movements
• 2.4.11 Focus Not Obscured (Minimum) / 2.4.13 Focus Appearance
• WAI-ARIA Button Pattern