I still remember the first time I really watched a video with the sound off. Not out of choice—I was crammed into a loud train, earbuds dead, trying to follow a conference talk. The captions were auto-generated garbage. “Asynchronous JavaScript” morphed into “a synchro nous Java crypt.” As a developer, and frankly as a person, I felt completely shut out. Building an accessible video player is less about checking a compliance box and more about crafting an interface that flexes to the user’s environment, their senses, their devices—without snapping. It’s creative, deeply technical work, and it starts long before you type a single HTML tag.

What follows is a walk through the practical side of building a custom player that works for people who are blind, deaf, have motor impairments, or just happen to be holding a baby with one hand. We’ll peek past the plain <video> tag into the weird corners of the Shadow DOM, the rhythm of ARIA, and the art of writing captions that actually sound human.

Why Native Controls Fall Short

Every browser gives you a default video player. It’s inconsistent, barely styleable, and its accessibility support is all over the map. In Chrome, the mute button might grab focus; in Firefox, the timeline slider becomes a black hole for screen readers. Leaning on native controls hands your users over to the browser’s whims. When we build from scratch, we own the markup, the behavior—and the responsibility.

The real knot is that a video player is basically a tiny operating system. It juggles state (playing, paused, buffering), time (current position, duration), volume, and fullscreen transitions. Each piece has to be exposed to assistive tech with clear, predictable meaning. A play button isn’t a <div> with a click handler; it’s a button with a pressed state, a label that shifts with context, and a focus ring you can spot in harsh sunlight.

Semantic Foundations: The Button Isn’t Just a Button

I start every player the same way: a no-JavaScript, accessible skeleton. The <video> element sits in the DOM, and I wrap real <button> elements, range inputs, and live regions around it. Here’s the backbone I lean on:

<div class="video-wrapper">
  <video src="my-video.mp4" poster="poster.jpg">
    <track kind="captions" src="captions.vtt" srclang="en" label="English" default />
    <track kind="descriptions" src="descriptions.vtt" srclang="en" label="Audio Description" />
  </video>
  <div class="controls" role="group" aria-label="Video controls">
    <button aria-label="Play" class="play-pause">▶</button>
    <input type="range" class="timeline" aria-label="Seek" min="0" max="100" value="0" />
    <button aria-label="Mute" class="mute">🔊</button>
    <input type="range" class="volume" aria-label="Volume" min="0" max="100" value="80" />
    <button aria-label="Captions" class="captions-toggle">CC</button>
    <button aria-label="Fullscreen" class="fullscreen">⛶</button>
  </div>
</div>

See the role="group" on the controls container? It nudges screen readers that these pieces belong together. The aria-label gives the whole set a name. Each button carries its own label that changes with state—when the video plays, “Play” flips to “Pause.” I handle that toggle in JavaScript, but the baseline already makes sense.

Making Range Inputs Sing

Range inputs for seeking and volume are notoriously finicky. For keyboard-only folks, I override the default arrow-key dance with custom logic: left/right arrows jump 5 seconds; Shift+left/right leaps 10 seconds. It respects power users who want fine control. I also drop in a live region that announces the current time while scrubbing:

<div aria-live="polite" aria-atomic="true" class="sr-only">
  Current position: 1 minute 23 seconds
</div>

That sr-only class hides the text visually but keeps it alive in the accessibility tree. Every time the user drags, the region updates and the screen reader calls out the new spot without stepping on the video’s audio.

Captions That Feel Human

Auto-generated captions have gotten better, but they still miss a speaker’s rhythm, the pauses, the punch. For a polished player, I hand-write WebVTT files—or at least edit the auto-crap intensely. A solid VTT file doesn’t just transcribe words; it telegraphs tone. I lean on voice spans to tell speakers apart and sprinkle in sound descriptions in brackets: [soft laughter], [door creaks]. A quick taste:

WEBVTT

00:00:03.000 --> 00:00:06.500
<v Luca>When I first started coding, I thought accessibility was about screen readers.</v>

00:00:07.000 --> 00:00:11.200
<v Luca>[chuckles] It’s so much more. It’s about how you hold your phone, how tired your eyes are.</v>

I style these cues with CSS pseudo-elements like ::cue and ::cue(v) to give each speaker their own text color and background. The captions toggle cycles through “off,” “English,” and a second language track if I have one. I stash the user’s choice in localStorage so it sticks across page loads—little details that make the player feel like a tool, not a toy.

Audio Descriptions Without Compromise

For blind and low-vision users, a separate audio description track isn’t optional. I use the <track kind="descriptions"> element and a WebVTT file with timed descriptions. The descriptions play through a hidden audio channel mixed with the main sound. Browsers don’t natively merge these, so I pull in the Web Audio API to spin up a second <audio> element and sync its playback with the video. It’s a bit hacky, but it means users get the full story without bouncing out of the player.

Keyboard and Focus: The Invisible Grid

Every control has to be reachable with the Tab key. I enforce a logical tab order that mirrors the visual layout. When the video ends, focus slides naturally to the replay button or the next video link. During fullscreen, I trap focus inside the player so keyboard users don’t accidentally wander into the browser chrome. A simple focus-trap utility listens for Tab and Shift+Tab on the player container.

I also dodge keyboard traps entirely. If a user hits Escape in fullscreen, they exit and focus returns to the button that triggered it. These moves feel smooth because they’re predictable. I test with just a keyboard, then with a screen reader running, then with both at once. It’s dull work, but it uncovers weird edge cases: a slider blurting “0%” when the video sits at 0 seconds but the user thinks it’s volume, for instance. Labeling fixes everything.

Motion and Timing: Respecting the User’s Settings

Some people get vertigo or nausea from quick animations. I check the prefers-reduced-motion media query and kill transition effects on controls when it’s active. My volume slider doesn’t bounce; it slides with a plain linear transition that I cut entirely if the user signals a reduced-motion preference. Similarly, I hold off autoplay and always keep a clear pause/play button visible on load. Autoplay feels like a cognitive ambush for many; I treat it as opt-in, never the default.

FAQ: The Questions I Get at Every Workshop

“Can’t I just use a framework like Plyr or Video.js and call it done?”

You could, but tread lightly. Plyr and Video.js pack accessibility features, but they’re not flawless out of the box. Plyr’s default focus styles are thin; Video.js’s control bar can spill over on small screens. I use them as starting points, then audit and patch the gaps myself. The HTML structure I mapped out earlier slots into any framework by overriding the default control markup. The trick is to never assume a third-party library did the heavy lifting. Run an audit with a screen reader and a keyboard—you’ll spot what needs fixing fast.

“How do I handle live video streams with real-time captions?”

Live streams are a whole different animal. Real-time captioning usually hooks into a CART (Communication Access Realtime Translation) provider or a speech-to-text service. On the tech side, you pull in a live caption feed—often through WebSocket—and inject cues into the player’s text track on the fly. I use the VTTCue API to add and remove cues as they land, and I keep a rolling buffer of the last 30 seconds of captions so latecomers can catch up. The player’s interface should also flash a clear indicator when live captions are running, so users know they’re reading machine-generated or human-typed text in the moment.

“What about touch devices? Swiping to seek messes up my slider.”

Touch accessibility often gets ignored. I fatten the seek bar to at least 48 CSS pixels tall for comfortable tapping and squash the default browser swipe-to-navigate gesture by calling preventDefault() on touch events inside the player container. For volume, I support a vertical swipe on the right edge of the player—similar to a lot of mobile video apps. This all sits behind touch-action: none on the controls panel, with careful event listeners that don’t trip up screen reader touch exploration. It’s a tightrope walk, but the result feels native.

Testing Beyond the Checklist

Automated tools like axe-core or Lighthouse catch maybe 30% of the problems. The rest are human: Does the captions button announce its state clearly? Can a switch-device user reach the fullscreen button in under 10 keystrokes? I test with NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Each has its quirks—VoiceOver treats <video> as a group; NVDA exposes it as an embedded object. I also run sessions with real users, not just coworkers. One low-vision tester pointed out my focus indicator vanished against a white background when the video had a white poster frame. I added a dynamic outline color that samples the poster’s average luminance—a tiny JavaScript snippet that grabs the image and sets a CSS variable.

Building an accessible video player is a process of endless tweaking. Every choice—button size, caption wording—decides who gets to join in. It’s not about flawless code; it’s about empathetic code. And when you watch someone glide through your player with a sip-and-puff device, or hear a screen reader confidently announce “Pause button, pressed,” you know you’ve built something that actually speaks to everyone.