Give every control a meaningful name
Use a button for playback and an accessible name that describes its current action. When the video is playing, the action becomes pause; the label should change accordingly. Keep decorative SVG paths out of the accessibility tree so they do not introduce a second, meaningless announcement.
SVG is useful because its appearance does not depend on a platform's emoji font. That consistency is not an accessibility guarantee. An unlabeled vector remains an unlabeled control. Also check that the visual state follows the media events themselves: a failed play request should not leave the button claiming that playback has started.
Keep pause reachable on touch and keyboard
A minimal player may hide controls during playback to give the video more room. If pause reappears only on hover, touch users lose that route. Provide a visible or explicitly revealable control on touch and show controls when keyboard focus reaches them. Avoid a design that requires guessing where an invisible button is positioned.
Check the usable target, spacing from nearby controls and focus visibility against the intended devices. WCAG 2.2 includes a minimum target-size criterion with exceptions, but designing exactly to a numerical boundary is not a substitute for comfortable operation. A small control over moving imagery can remain difficult to find even when its geometry passes a rule.
Audit the information in the media
Listen without watching, then inspect what the visual track communicates independently. Spoken words need an appropriate text alternative; important visual information may require description or an equivalent media alternative depending on the content and applicable criteria. A transcript should represent the actual media, not a paragraph written from its filename.
The W3C media guidance distinguishes captions, transcripts and audio description because they solve different access problems. Captions can include meaningful non-speech audio as well as dialogue. A branding video containing on-screen claims also needs those claims to be available to people who cannot see the animation. Attractive controls do not address that content gap.
Retain a dependable fallback
Custom controls should improve an experience that has a usable baseline. Where practical, keep native controls available until the custom interface is ready and provide a direct media link when playback fails. Do not show a permanently inert play button when JavaScript or the media request fails.
Load the video according to the user's intent. A poster with reserved dimensions can keep a page stable while the media waits for interaction. Avoid unexpected sound. If the video repeats or starts automatically, assess motion and stopping requirements separately. Respecting reduced motion for page decoration does not automatically control a playing video.
Verify a complete viewing task
Try reaching play with the keyboard, starting playback, pausing, navigating away and returning. Repeat on a touch device with a screen reader if that is within the supported audience. Then verify that captions or a transcript can actually be found from the player. A transcript hidden on an unrelated page does little for someone trying to understand the current video.
Record what was tested and what is unresolved. If captions have not been checked against the audio, do not describe the player as fully compliant. A useful delivery note separates control behaviour, media alternatives and device testing; each needs its own evidence before making a broader accessibility claim.
- Labels match the current playback action.
- Pause remains reachable without hover.
- Text alternatives match the actual content.
- Failure and no-JavaScript paths remain usable.
References
Working through a similar product problem?
Tell me about the workflow, the team and the constraints. They are a concrete starting point for discussing interfaces and frontend development.
Start a conversation by email