The player is the heart of your podcast website. A visitor can ignore your about page, your newsletter form and your sidebar, but if they cannot press play, nothing else matters. Many embedded players look polished and still fail basic accessibility checks. They hide controls from keyboards, use icons with no names, or trap focus inside a frame. This guide gives you a practical way to judge a player before you put it on your site, and to cope when the one you have is not good enough.

The bare minimum

Three requirements form the floor. If a player fails any of them, it is not ready for public use.

1. Keyboard operable. Every control can be reached and used with Tab, Enter, Space and the arrow keys, with no mouse needed.
2. Visible focus. When a control receives keyboard focus, you can clearly see which one it is.
3. Labelled controls. Each button, slider and menu has a name that a screen reader announces, such as “Play”, “Pause”, “Playback speed” or “Volume”. An unlabeled icon button is announced as just “button”, which is useless.

Beyond these, a player should also tell assistive technology about its state. When you press play, the button should change its name to “Pause” or announce that it is pressed. Otherwise a blind listener cannot tell whether anything happened.

Controls that matter for listeners

Podcast listeners need more than a play button. Look for the following.

• Play and pause that work with Space or Enter.
• Skip back and skip forward by a fixed jump, handy for replaying a missed sentence.
• Playback speed. Slower speeds help people who process audio more gradually, and faster speeds help those pressed for time or reading along with a transcript.
• Volume control that is separate from the device volume, with a mute option.
• A progress slider that can be moved with arrow keys, with Home and End for the start and finish.
• Time display as real text, showing elapsed and total time.

The progress slider deserves special attention. It should announce its value in words that make sense, such as “12 minutes 30 seconds of 45 minutes”, rather than a bare percentage or a raw number of seconds. A slider that can only be dragged with a mouse excludes everyone who relies on a keyboard, voice control or switch access.

Autoplay and surprise sound

Audio that starts on its own is one of the worst things a podcast page can do. Screen reader users hear their reader’s voice fighting with your show, and nobody wants a surprise burst of sound in a quiet room. Choose a player that does not autoplay by default, and do not switch it on. If any audio ever plays automatically for more than three seconds, the visitor must be able to pause it or silence it easily.

Let listeners decide when the sound starts.

A checklist for evaluating a player

Use this list when you compare options or review your current one.

• Can I reach every control with Tab and Shift+Tab, in a sensible order?
• Does each control respond to Enter or Space?
• Can I always see the focus indicator, against both light and dark themes?
• Does every control have a clear text name?
• Do state changes, like play to pause or mute on and off, get announced?
• Can the progress slider be used by keyboard, and does it announce readable times?
• Is there a speed control and a skip control?
• Does it avoid autoplay?
• Do icons and text meet contrast requirements, with 3:1 for icons and 4.5:1 for normal text?
• Does it still work when the page is zoomed to 200%, and on a small phone screen?
• Is there a way to leave the player with the keyboard, with no trap?
• Does it work without needing a fast connection? Many people near Ottawa, Canada can only get about 5 Mbps, so a heavy player that loads slowly punishes them.

How to test a player in ten minutes

1. Open a page with the player and put the mouse aside.
2. Press Tab until you reach the player. Note whether focus is visible at each stop.
3. Start playback with Space or Enter, then pause it.
4. Change the speed, adjust the volume, skip forward and back, and move the slider with the arrow keys.
5. Turn on a screen reader and repeat. Listen for control names and state changes. Note anything announced only as “button” or “slider” with no name.
6. Zoom to 200% and check that nothing overlaps or disappears.
7. Test on a phone, since mobile screen readers and browsers sometimes behave differently.

What to do if your host’s player is poor

Many podcasters use whatever player comes with their hosting. If yours fails the checks above, you still have options, and you do not have to abandon your host.

• Report it. Send the provider your specific findings, such as “the volume button has no accessible name”. Concrete reports are more likely to be acted on than a general complaint.
• Use the browser’s built-in audio element. A plain HTML audio element with controls is operable by keyboard and announced by screen readers in current browsers. It is not fancy, but it is dependable.
• Offer a direct audio file. Provide a download option next to the player, so people can open the episode in the listening app they already trust.
• Link to the show in major directories. Listeners can then use the player they like best. Keep the wording in text, such as “Listen in your podcast app”.
• Add a transcript. Whatever the player does, a transcript gives everyone another way to take in the episode.

Ask about accessibility before you sign up with a new host. A good provider will be able to tell you how they test, not just assure you that they care.

Final thoughts

You do not need a perfect player, but you do need a usable one. Treat keyboard operation, visible focus and clear control names as non-negotiable, then look at the extras like speed and skip controls. Test before you commit, retest after updates, and keep a fallback in place, such as a plain audio element or a download link. When everyone can press play, everything else on your site has a chance to be heard.