An accessible audio player: the criteria the player itself has to meet

There is a common irony in accessibility projects: you add an audio player to better serve people who read with difficulty or not at all, and the player itself can only be used with a mouse, with no label for a screen reader, with invisible focus and a progress bar you cannot move from the keyboard. The remedy becomes one more obstacle. A component that talks about accessibility has to start by being accessible itself, otherwise it just moves the problem somewhere else.

So here, concretely, is what our player meets. Not a list of good intentions: behaviours you can verify by opening the player's code, which we describe here because a public buyer has every right to check them before signing.

Everything works from the keyboard

The first thing a listener will try, and the first thing an accessibility auditor tries, is the Tab key. The progress bar in our player is a slider you can reach from the keyboard: once it has focus, the right arrow jumps forward ten seconds, the left arrow jumps back the same, the Home key returns to the start, the End key jumps near the end, and Space or Enter play or pause. The play button announces its own state: its label flips between "Play" and "Pause" depending on what is happening, and that change is signalled so a screen reader relays it.

Chapters, when an article has them, are not a decorative list: each chapter receives focus and plays with Enter or Space, and the current chapter is marked as such for the device's speech output. The "Chapters" and "Text" panels declare whether they are open or closed, so a screen reader never offers to enter a panel that is not there.

Reading comfort is announced, not just displayed

The text panel, which shows the article while it is being read, carries a group of comfort controls: enlarge or shrink the text, loosen the line spacing, switch to high contrast, switch to a more legible typeface. Each of these controls is a button that states whether it is on or off, so that a screen reader user knows the state they are in without having to guess. High contrast mode is not a simple dimming: it sets a black background, white text, and highlights the word currently being read in yellow, which serves both low vision and reading follow-along, as we explain in our note on synced text.

Focus is visible, and motion calms down

Invisible keyboard focus is as useless as no focus at all: you cannot tell where you are. The player's interactive elements keep a visible focus outline, with an offset that detaches it from the edge. And for people whom animation bothers or makes unwell, the player honours the system "reduced motion" preference: the loading animation stops, and the scrolling of the read-along text becomes instant rather than gliding. This is not a setting inside the player, it is the preference the person has already set in their operating system, which the player simply respects.

What stays the site's job

Let us be honest about the limits, because that is where misunderstandings get expensive. Two things in particular.

First, the comfort controls act on the player's text panel, not on the page around it. The player cannot restyle your article, your menu or your sidebars: it only has authority over itself. Second, the player's default colours inherit from your site's. The high contrast button guarantees a legible result whatever happens, but the default rendering is only as good as your palette: a player dropped onto a light grey background with mid grey text will stay low in contrast until someone touches the colours.

Above all, and we are glad to repeat it, an accessible player does not make your site compliant. Keyboard operation of the whole page, heading structure, image alt text, the skip link: all of that is the foundation of WCAG and belongs to the site, not the player. We go into that distinction in our article on the audio version versus the screen reader, which are two different kinds of accessibility. If you are wondering how the player gets added to your site without a rebuild, our WordPress page describes the available routes and what they do (or do not) touch in your theme.

Check it yourself

The best proof is not an article, it is the Tab key. Switch on our audio player on an article, put your mouse away, and go through it from the keyboard. If something resists you, that is exactly what we want to know.

Read next

• Writing for the ear: what reads well and listens badly
• Internal comms as audio: what changes when the text must stay inside the company
• Listening to a long text in French TTS: listening fatigue, and what actually helps