By Luca Fontana

Think about a deaf user staring at a product demo without captions. Or someone blind who can’t start the video because their screen reader doesn’t register the play button as a real control. Video is the web’s most expressive channel, yet it slams the door on people the second we forget that not everyone clicks with a mouse. Some folks tab. Others listen. A few feel their way through a Braille display. Making a video player truly usable isn’t a compliance checkbox—it’s about making sure the story you’re telling lands with everyone who shows up to hear it.

I’m Luca Fontana. I’ve spent years building custom players for clients who wanted slick design and rock-solid WCAG conformance. This isn’t theory. It’s a blueprint stitched together from real code, real user feedback, and the occasional facepalm moment that taught me something I should have known all along.

Start With Semantic HTML, Not a Blank Canvas

I get the temptation. You want custom controls, so you grab a handful of <div> tags and start painting. But the browser’s native <video> element already carries a lot of accessibility weight—keyboard handling, caption rendering, hooks into the operating system’s accessibility layer. Wrap that element in opaque containers and you’re throwing away all the free stuff. Keep the native video tag in the DOM. Layer your custom chrome on top with JavaScript and CSS, but leave the original element right where assistive tech can find it.

A solid starting point is dead simple:

<video controls crossorigin="anonymous" poster="thumbnail.jpg">
  <source src="video.mp4" type="video/mp4" />
  <track kind="captions" src="captions.vtt" srclang="en" label="English" />
</video>

See that controls attribute? It’s your safety net. If your fancy JavaScript takes a second to load, the user still gets a working player. Only disable the native controls after your custom ones are fully baked and tested. You don’t want to leave somebody hanging with an unplayable video because a script hiccuped.

Building Controls That Respond to More Than a Mouse

Every interactive doodad—play/pause, volume, the scrubber, the captions toggle—needs to be a proper <button> or an ARIA-augmented element that behaves like one. A div with a click handler won’t respond to the Enter or Space keys by default, and a screen reader won’t announce it as something you can press. Just use <button> for discrete actions and <input type="range"> for sliders. You’ll get focus management, keyboard interaction, and the right role announced without writing a single extra line of JS.

For the seek bar, wire the range input’s aria-valuenow to the video’s current time and keep it in sync on timeupdate. Something like this:

const seekBar = document.querySelector('.seek-bar');
video.addEventListener('timeupdate', () => {
  seekBar.value = video.currentTime;
  seekBar.setAttribute('aria-valuenow', video.currentTime);
});
seekBar.addEventListener('input', () => {
  video.currentTime = seekBar.value;
});

Don’t skimp on the volume control. A mute toggle is a blunt instrument. People with auditory processing issues often need to dial in a specific level. Pair the slider with a live region that announces the volume change, so a screen reader user knows exactly where they’re at without guessing.

Focus Traps and Visible Indicators

When someone tabs into your player, the focus outline better be obvious. Killing it with outline: none without a replacement is a quick way to lose keyboard users entirely. I like a thick, high-contrast ring that borrows the site’s accent colour. If your player goes fullscreen or pops up in a modal, trap the focus inside: pressing Tab should cycle through the controls, not wander off to the cookie banner behind the overlay. It’s a small thing that stops big confusion.

Captions, Transcripts, and Audio Descriptions

Captions are the poster child of video accessibility, and yet I still see them done half-heartedly. WebVTT is the standard, and browsers support it natively. Use the <track> element, and provide at least one caption file. But captions are just the start.

A transcript is what a deaf-blind person uses with a refreshable Braille display. It’s also a lifesaver for someone in a loud café or a library. Drop a transcript below the player, link it with aria-describedby, or offer a clean downloadable version. If your video shows something visual that the narration doesn’t mention—like a graph popping up with no comment—you need an audio description track. The <track kind="descriptions"> attribute is there, but you’ll have to script your own toggle because browsers don’t expose a UI for it. Yeah, it’s extra work. Do it anyway.

When you’re writing captions, put some soul into them. Note who’s speaking, add sound effects, mention the music. For instance:

WEBVTT

00:00:05.000 --> 00:00:08.000
[Luca] Let's test the new player build.

00:00:08.500 --> 00:00:12.000
[clicking keyboard]

This turns a dry technical requirement into something that actually conveys what’s happening. It’s not just text on a screen; it’s part of the storytelling.

Colour, Contrast, and Motion Sensitivity

Accessibility doesn’t stop at the code editor. Your player’s visuals have to pull their weight. WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for big icons. Buttons need distinct hover, focus, and active states that don’t depend only on colour. I usually mix a background shift, a thicker border, and a tiny scale bump—something you can feel with your eyes even if you can’t distinguish red from green.

Motion sensitivity is another one that gets swept under the rug. Autoplaying videos can make people with vestibular disorders physically sick. Always check the prefers-reduced-motion media query. If it’s active, kill autoplay and strip out decorative animations like a pulsing play icon. A quick CSS rule does the trick:

@media (prefers-reduced-motion: reduce) {
  .player__play-button {
    animation: none;
  }
  video[autoplay] {
    display: none; /* or pause via JS */
  }
}

Testing With Real Tools and Real People

Automated checkers find maybe 30% of the problems. The rest you have to hunt down yourself. Fire up a screen reader—NVDA on Windows, VoiceOver on a Mac—and close your eyes. Can you play the video? Pause it? Jump ahead? Tweak the volume? Does the screen reader announce every state change? Now unplug your mouse and do it all again with just the keyboard. If you trip up, so will your users.

I also crank the browser zoom to 200%. Controls need to stay visible and not overlap. Flexbox and relative units like rem and percentages make this hold up. When you think you’re done, ask people with disabilities to take it for a spin—and pay them for their time. Their feedback will expose assumptions you didn’t even know you were carrying.

Frequently Asked Questions

Why can’t I just use the browser’s default video controls?

You totally can, and often you should. Native controls have been hammered on for accessibility. Custom controls make sense when you need a consistent look or extra features like playback speed or quality toggles. If you roll your own, copy the native keyboard shortcuts and ARIA roles faithfully, so nobody loses features they already rely on.

How do I make video embeds from YouTube or Vimeo accessible?

Embedded players grab some baseline accessibility from the platform, but your job isn’t done. Give the iframe a descriptive title attribute. Supply your own captions if the auto-generated ones are sloppy. Put a transcript outside the iframe. With YouTube, you can tack on parameters like cc_load_policy=1 to force captions on, but don’t override the user’s preference unless they’ve clearly opted in.

What is the simplest way to add captions to a self-hosted video?

Write a WebVTT file and wire it up with a <track> element. Plenty of free tools can rough out the timings from a transcript. Then go in and clean it up yourself—auto-timing loves to misalign sentences and scramble meaning. If you’re in a hurry, you can even write the VTT file by hand in a text editor with the format I showed earlier.

Do accessible players hurt performance or design flexibility?

Not at all. Semantic HTML and a few ARIA attributes add basically zero overhead. A clean custom player can be both lightweight and gorgeous. The trick is baking accessibility into the architecture from the first wireframe, not slapping it on after the CSS is finalized. When you do it early, it feels like a natural piece of the design, not some awkward bolt-on.

Accessibility isn’t a feature tacked onto a spec sheet. It’s the bedrock of a web that holds up for everyone. When you build a video player that anyone can operate, you’re doing more than meeting guidelines—you’re acknowledging the actual human on the other side of the glass. And really, that’s what good engineering is all about.