Module 4.1: Why Keyboard Access Matters: Beyond Mouse Users

When most people think about web accessibility, they picture captions or screen readers. Keyboard accessibility rarely gets the same attention — but it affects a surprisingly wide range of people who interact with your agency's digital content every day.

Think about what it means for a resident who can't use a mouse to watch a recorded city council meeting. They may not be able to press play, rewind to catch a vote, or turn on captions. That's a real barrier to participating in civic life — and it's one that keyboard-accessible video players can remove.

This article explains what keyboard accessibility is, who depends on it, and why supporting it serves your whole community — not just one specific group.

What keyboard accessibility means

Keyboard accessibility refers to the ability to use all functions on a webpage — including video players — using only a keyboard, without a mouse or touchpad.

In practice, that means a user should be able to Tab through controls, press Enter or Space to activate buttons, use arrow keys to seek through a video, and exit any focused element without getting stuck. The experience should feel logical, predictable, and complete.

WCAG 2.1 addresses this directly under Guideline 2.1: Keyboard Accessible. Two success criteria are relevant here, and both sit at Level A — the foundational tier that applies at every compliance level, including Level AA.

WCAG Success Criterion 2.1.1 – Keyboard (Level A) requires that all functionality on a page be operable through a keyboard interface, without requiring specific timing for individual keystrokes.

WCAG Success Criterion 2.1.2 – No Keyboard Trap (Level A) requires that if a user can move keyboard focus into a component, they must also be able to move focus away using only the keyboard. Getting stuck inside a video player with no way out is exactly what this criterion is designed to prevent.

Because these are Level A requirements, they are non-negotiable at every compliance level. Agencies working toward the April 2027 ADA Title II milestone need to treat keyboard accessibility in video players as a foundational item — not an optional enhancement.

Who relies on keyboard navigation

Keyboard accessibility isn't built for one type of user. It serves several distinct groups, each with different needs and different technologies.

People with motor disabilities

People who have limited hand mobility, tremors, or conditions affecting fine motor control may find a mouse difficult or impossible to use. This includes people with conditions such as multiple sclerosis, cerebral palsy, spinal cord injuries, or repetitive strain injuries. For these users, a keyboard — or a device that sends keyboard commands — may be the only practical way to interact with a computer.

Motor disabilities are among the most common disability types reported by U.S. adults. For a city or county government, that means a meaningful portion of your service population may be relying on keyboard navigation to access your public meeting recordings on any given day.

Screen reader users

A screen reader is software that reads on-screen content aloud for people who are blind or have low vision. Common examples include JAWS, NVDA, and VoiceOver (built into Apple devices). Screen readers depend entirely on keyboard navigation — they don't use a mouse at all.

When a person using a screen reader encounters a video player, they need to move focus through the controls in a sensible order, understand what each control does, and activate it with a keystroke. If the player wasn't built with keyboard support, that person may not be able to locate the play button — let alone toggle captions.

Switch access users

Some people use switch access — a method where one or more physical switches (buttons, paddles, or sip-and-puff devices controlled by breath) cycle through on-screen options and select them. These devices send standard keyboard commands to the computer, so they depend entirely on keyboard accessibility to function.

Other alternative input devices include eye-tracking systems, head pointers, and mouth sticks. All of these ultimately translate user actions into keyboard commands. If a page doesn't support keyboard navigation, none of these devices can bridge the gap.

Voice control users

Voice control software — such as Dragon NaturallySpeaking or the built-in Voice Control tools in Windows and macOS — lets users navigate and interact with computers by speaking commands. Voice control often works by speaking the visible name of an on-screen element, or by issuing spoken keyboard shortcuts.

People who use voice control may have motor disabilities, chronic pain, or other conditions that make extended typing difficult. Solid keyboard accessibility makes voice control work more reliably for all of them.

People with temporary or situational limitations

Keyboard accessibility also supports people without a permanent disability. Someone recovering from a hand injury, a staff member who prefers keyboard navigation for efficiency, or a resident on a small touchscreen in an awkward position may all benefit from the same design decisions you make for users who depend on them daily.

This is sometimes called the curb cut effect: design improvements made to serve people with disabilities often create a better experience for a much wider group. The ramps built for people who use wheelchairs are also used by delivery workers, cyclists, and parents pushing strollers. Keyboard accessibility works the same way.

How assistive technology uses the keyboard

Understanding how these tools actually work helps clarify what "good" keyboard accessibility looks like in practice.

Screen readers and focus order

When a person using a screen reader lands on a page, they navigate using Tab to move between interactive elements and arrow keys to read content. The sequence in which focus moves through the page is called the focus order, and it should reflect the visual layout and logical reading sequence of the page.

For a video player, a sensible focus order might move from Play/Pause to Volume to the Seek bar to Caption toggle to Full screen. If that order is scrambled — jumping to full screen before volume, for example — it creates a confusing experience even if all the controls are technically reachable.

Screen readers also depend on focus indicators — the visible outline or highlight that shows which element is currently active. WCAG 2.4.7 Focus Visible (Level AA) requires that keyboard focus always be visible. Some design teams remove focus indicators because they find them visually disruptive, but this makes keyboard navigation nearly impossible for any sighted user who relies on a keyboard to get around.

Switch access and tab stops

People using switch access navigate by cycling through focusable elements one at a time, often slowly. Every extra tab stop adds time and effort. A video player with ten separate controls means ten cycle-throughs just to reach the last one.

Good keyboard design minimizes unnecessary tab stops and groups related controls logically. Placing the most-used controls — play/pause, volume — early in the focus order helps all keyboard users, but it makes a particularly meaningful difference for switch access users.

Voice control and visible labels

Voice control users navigate by speaking the visible name of an on-screen element — for example, saying "click Play" to activate the play button. This works well when the visible label on a button matches its underlying accessible name in the code.

When developers build custom video players with unlabeled icon buttons, voice control users may have no visible name to speak. WCAG Success Criterion 2.5.3 Label in Name (Level A) addresses this directly: the accessible name of a control must contain the text that is visually presented to users. A play button labeled "Play" on screen but coded with a different or missing name will break voice control navigation entirely.

What this looks like in practice

Consider a resident who wants to watch a recorded planning commission meeting on your agency's website. They have low vision and use a screen reader.

They navigate to the video player. If the player is well-built, they can Tab to the play button, hear it announced as "Play, button," press Enter to start the video, and use arrow keys to seek forward. Caption controls are reachable, labeled, and respond to keyboard input.

If the player is poorly built, here's what may happen instead: the play button has no accessible label and can't be reached with Tab. The screen reader announces it as empty. The caption button is visible on screen but buried behind a submenu that has no keyboard access. The resident cannot engage with the content at all.

This scenario is common with video players that were not designed with accessibility in mind. It means residents with disabilities can't access records of meetings that directly affect their communities — budget decisions, zoning changes, public safety updates. Keyboard accessibility is what keeps that door open.

Testing keyboard accessibility on your own site

You don't need specialized software to run a basic keyboard accessibility check. Here's a straightforward approach:

1. Set your mouse aside or disable your trackpad.

2. Navigate to the page with your video player using Tab and Shift+Tab.

3. Confirm you can reach every control — play, pause, volume, seek bar, captions, and full screen.

4. Verify that you can see which element has focus at all times (look for a visible outline or highlight).

5. Press Escape or Shift+Tab to confirm you can exit the player without getting stuck.

6. Check that the Tab order follows a logical, left-to-right and top-to-bottom sequence.

If you get stuck anywhere or if controls are unreachable, document what you find and share it with your web team or video platform vendor. Even if you can't fix it yourself, identifying the failure is a meaningful first step.

MediaScribe integration

Keyboard accessibility for video content depends on both how your video player is built and how accessibility features — like captions — can be activated within it. MediaScribe-generated captions are delivered as standard WebVTT caption files that can be loaded into any WCAG-compliant video player. When captions are properly embedded in a player that supports keyboard navigation, users can reach and toggle the caption control using only their keyboard — no mouse required.

When evaluating your video player for keyboard accessibility, check whether your caption control is reachable by Tab, has a visible label, and responds to Enter or Space. If your player doesn't meet that bar, switching to a WCAG-compliant player and loading your MediaScribe caption files into it is a practical path forward. In the next article, we'll walk through the specific keyboard controls a video player must support to meet WCAG 2.1 requirements.

Key takeaways

• Keyboard accessibility means all video player functions can be operated using only a keyboard, with no mouse required.

• WCAG 2.1 Success Criteria 2.1.1 and 2.1.2 are Level A requirements — they apply at every compliance level, with no exceptions.

• People who rely on keyboard navigation include people with motor disabilities, screen reader users, switch access users, voice control users, and people with temporary or situational limitations.

• Assistive technologies like screen readers, switch devices, and voice control all depend on keyboard accessibility to function correctly.

• Good keyboard design includes a logical focus order, visible focus indicators, and accurately labeled controls.

• A basic keyboard accessibility check requires no special software — just Tab, Shift+Tab, arrow keys, and careful observation.

• Accessible video players keep public meeting records reachable for every resident in your community.