Accessibility

How Video.js approaches accessible media playback, covering standards, ARIA, keyboard, captions, contrast, touch targets, and user preferences.

Video.js handles accessibility out of the box so your player works for everyone.

Standards we target

WAI-ARIA 1.2 defines roles, states, and properties that assistive technologies use to understand controls.
WCAG 2.2 provides success criteria for perceivable, operable, understandable, and robust web content.
CVAA is a U.S. federal law requiring closed captioning and accessible controls for video content.
ADA is a U.S. civil rights law that prohibits disability discrimination. Courts increasingly apply it to websites, including video players.

ARIA roles and labels

Components set ARIA roles and attributes automatically. For example, sliders render with role="slider" and value attributes, buttons update their aria-label based on player state, and decorative elements like time separators are hidden with aria-hidden="true".

Verify that labels are contextually correct for your content and language. Each component’s reference page documents the attributes it sets.

Keyboard interaction

All interactive components support keyboard control. For example, buttons activate with Enter and Space, sliders respond to Arrow keys, Home, End, and Page Up/Page Down, and popovers close with Escape. Each component’s reference page lists its full keyboard support. We follow the patterns in the WAI-ARIA Authoring Practices Guide.

Focus management

Interactive elements are focusable when enabled and leave the tab order when disabled. Popover triggers link to their popups with aria-controls and aria-expanded.

Captions and subtitles

The text tracks feature supports captions and subtitles. Closed captions in the U.S. are governed by the FCC under the CVAA, which requires both captioning and viewer control over caption appearance (font, size, color, opacity, and edge style). Non-compliance carries legal risk. The WebKit Caption Display Settings explainer tracks how browsers are bringing these customization preferences into the web platform natively.

Color contrast

Skins respond to prefers-contrast: more by increasing background opacity on overlays and controls, and to prefers-reduced-transparency: reduce by raising baseline opacity so text stays readable over video.

Video is harder than most UI for contrast because the background is always changing. A control that passes checks over a dark frame can disappear over a bright title card. Automated tools won’t catch this, so test your controls against light, dark, and mixed video content. Custom components should test against WCAG 1.4.3 (contrast minimum) and 1.4.11 (non-text contrast).

Touch targets

Controls use rem-based sizing so they scale with the user’s font size preference. All interactive elements set touch-action: manipulation to eliminate tap delay on touch devices. Skins use pointer: fine and pointer: coarse to adapt transitions for mouse and touch input.

If you build custom controls, target at least 24x24 CSS pixels per WCAG 2.5.8 (target size minimum). Larger is better on touch-first surfaces.

Color scheme

Skins adapt to prefers-color-scheme. Borders, backgrounds, and text colors adjust through CSS custom properties. Custom components can use the same design tokens. See Skins for details.

Reduced motion

Skins respect prefers-reduced-motion by simplifying or removing animations and transitions. Follow the same pattern in custom components.

Test with assistive technology

Automated tools catch markup issues but miss real usability problems. Test your player with a screen reader (VoiceOver on macOS, NVDA or JAWS on Windows) and keyboard-only navigation. Verify that every control is reachable, operable, and announces its purpose and state. The WAI “Easy Checks” are a good starting point.