Every video control, from play and pause to volume and captions, must work from the keyboard with a visible focus outline. Test each player with the mouse put away, and replace click-only overlays and pop-ups.

A play button that is only a picture

Many business sites show a video as a still image with a triangle drawn on it. Click it with a mouse and the video plays.

Press the Tab key instead, the way people who cannot use a mouse move through a page, and the triangle may never be reached. To a screen reader, it may be announced as an image, or not at all.

People who rely on a keyboard include those with tremors, limited hand movement or repetitive strain, and blind people using screen readers. Many others simply prefer it.

For all of them, a video they cannot start, pause or turn down is a closed door.

What a keyboard user needs

The fifth turns an inconvenience into a dead end. A player that captures the Tab key, or a pop-up player with no keyboard way to close it, leaves someone unable to reach anything else on the page.

What WCAG 2.0 asks for

WCAG 2.0, the standard most accessibility work is measured against, covers this directly.

Everything a page does must work from a keyboard, and nothing may trap the keyboard in one place. Both are at Level A, the most basic level.

Level A also asks for control names that assistive technology can read, so a button is announced as play rather than as nothing.

Level AA adds that the focus must be visible, so a keyboard user can see which control is active.

Audio that starts on its own and plays for more than a few seconds needs a way to pause it or turn it down, and recorded video with speech needs captions.

Where the problems come from

Video players that fail usually were not built as players at all.

Theme sliders, page builder sections and lightbox plugins often wrap a video in their own click-only image or overlay. Background videos in page headers often play with no control at all.

Some themes also remove the focus outline entirely, because a designer disliked the box that appears around a clicked button. That one line of styling hides where the keyboard is on every page of the site.

And icon-only buttons with no text label leave a screen reader announcing "button" and nothing else.

Testing with the keyboard

Push the mouse out of reach and work down the page with the Tab key alone. Watch where the focus goes, and count how many presses it takes to reach the video.

When the player has focus, try Enter and the space bar, then tab through its controls: play, volume, captions, full screen. Press Escape to leave full screen, then keep tabbing to confirm you can move past the player.

Test in Firefox or Chrome. Safari on a Mac skips links and buttons with the Tab key unless a setting is changed, which makes every site look worse than it is.

A worked example

A counselling practice with five counsellors added a short introduction video to each counsellor's page, because people choosing a counsellor want to hear the person first.

Each video sat behind a still photograph with a play symbol drawn on it. Clicking the photograph opened the video in a pop-up over the page.

With a keyboard, the photograph could not be reached. It was a picture with a click script attached, not a button, so Tab skipped straight past it, and a screen reader announced only an image.

The pop-up had no close button the keyboard could reach, and Escape did nothing. The theme had also removed the focus outline, so even the links that worked were hard to follow.

The fix replaced the photographs and pop-ups with the standard player from the service hosting the videos, embedded directly on each page. The focus outline came back, the automatic captions were corrected, and a written transcript went under each video.

Pop-up players

If a video has to open over the page, the pop-up needs to behave in four ways.

Focus moves into it when it opens, and Tab keeps cycling within it while it stays open.

Escape and a visible close button both shut it, and focus returns to the button that opened it, so the visitor is not dropped back at the top of the page.

Usually, a player embedded directly in the page is simpler than any pop-up.

Choosing a player that works

The standard embedded players from the major video services can generally be operated from the keyboard, with labelled controls and caption options. They still deserve the five-minute test on your own page.

Video files played through the browser's own controls vary from browser to browser, so test the ones your customers use.

Players built with accessibility in mind exist, some of them free. Whatever you choose, ask for keyboard access in writing when a developer adds video, so it is part of the job rather than a repair.

Captions and transcripts

Captions serve people who are deaf or hard of hearing, and everyone watching on a phone with the sound off.

Automatic captions are a starting point, not a finished job. They stumble on names, local places and technical terms, which are often the words that matter most.

A transcript under the video helps screen reader users and anyone who would rather read, and it puts the video's words where search engines can find them.

The counter-case

Not every video needs the same attention.

A short decorative clip with no sound carries less weight than a video explaining your services, though motion lasting more than five seconds still needs a way to pause it.

A site with one old video nobody watches might reasonably remove it.

Start with the videos that carry information people need to choose you. Make those work from the keyboard, with captions, before anything else.

The check

  1. Put the mouse out of reach for ten minutes.
  2. Tab to each video from the top of the page.
  3. Start and pause it with Enter and Space.
  4. Tab past it to confirm nothing traps you.
  5. Look for the focus outline at every step.
  6. Correct the captions on each video.
  7. Add a transcript below the important ones.

Step four is the one that separates an annoying player from one that blocks the whole page. A visitor who cannot get out of a player cannot reach the contact details beneath it either.

The intake forms that often sit beside those videos are covered in application forms that have to be printed.

Frequently asked questions

Who relies on the keyboard to use a site?

People with tremors, limited hand movement or repetitive strain, blind people using screen readers, and many others who simply prefer it to a mouse.

What does WCAG 2.0 require of video players?

Everything must work from a keyboard with no keyboard trap, focus must be visible, controls need readable names, and recorded video with speech needs captions.

Why do some players fail the keyboard test?

They are often a picture with a click script rather than a real button, or a pop-up with no keyboard way to close it, inside a theme that hides the focus outline.

How do I test a player?

With the mouse out of reach, tab down to the video, start and pause it, try each control, and keep tabbing past it to confirm nothing traps you.

Which players tend to work?

The standard embedded players from the major video services generally work from the keyboard, though each still needs testing on your own page. Click-only overlays usually do not.

Are automatic captions good enough?

They are a starting point. They often get names, places and technical terms wrong, and those are usually the words that matter, so correct them before relying on them.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Videos that need a mouse?

Send us the page. We will test each player with the keyboard and tell you what needs replacing.

Start a Conversation