You don’t need a consultant or a lab to find out whether your podcast site and player work for people with disabilities. A handful of simple checks, done in about an hour, will reveal most of the serious problems. You won’t catch everything, and you shouldn’t claim your site is fully accessible after a self-audit, but you’ll learn a great deal about where you stand.

Pick one episode page and your home page, then work through the steps below. Keep a notes file open and write down every problem as you find it.

Step 1: The keyboard test

Put your mouse aside. Click in the address bar, then press Tab to move through the page. Use Shift+Tab to go backwards, Enter to activate links and buttons, and Space for the play button.

As you go, ask:

• Can you reach every link, button and player control?
• Is it always clear where you are? A visible focus indicator, such as an outline or highlight, should follow you.
• Does the order make sense, or does focus jump around the page?
• Can you get out of every widget, or does focus get trapped in a pop-up or embedded player?
• Can you play, pause, skip and change volume using only the keyboard?

Failing here is serious, because many assistive technologies rely on the same keyboard behavior. If you can’t operate something without a mouse, a lot of people can’t use it at all.

Step 2: Zoom to 200%

Use your browser zoom to enlarge the page to 200%. Text should be resizable to that level without losing content or function. Scroll through and check that nothing is cut off, overlapping or hidden, and that you don’t have to scroll sideways to read a line of text. Try it again with a narrow browser window, which approximates a phone.

Step 3: Contrast and color

Low contrast is one of the most common problems, and it’s easy to measure. Normal-size text should have a contrast ratio of at least 4.5:1 against its background. Free contrast checker tools let you enter two colors and see the ratio. Check your body text, links, buttons, placeholder text in forms and any text over images.

Then look for information carried by color alone. If a link is only distinguished from the surrounding text by being blue, or an error is only shown in red, add another cue such as underlining or a text label. About 8% of men are color blind, so this isn’t a rare edge case.

If you can only do one test today, tab through your episode page. It exposes more problems per minute than any other.

Step 4: A screen reader pass

Most computers and phones include a built-in screen reader, and free ones exist for others. Learning one properly takes time, but even a basic pass is revealing. Turn it on, close your eyes or dim your screen, and move through your episode page.

Listen for:

• A page title and headings that describe the content. Many screen reader users jump from heading to heading, so a logical outline matters.
• Player buttons announced with names such as “Play” or “Mute”. A button read aloud only as “button” is missing a label.
• Images with sensible alternative text, and decorative ones skipped.
• Links that make sense out of context. Several links all called “click here” or “read more” are confusing in a list.
• Any content that appears or changes without being announced.

Expect to feel clumsy at first. That’s normal, and it’s also a reminder that experienced users are much faster than you. Don’t judge usability solely by your own struggles.

Step 5: Transcript and player labels

Check the transcript itself. Is it on the page or easy to find from it? Is it accurate, with speaker names and meaningful sounds noted? Is it structured with paragraphs rather than one dense block? Does it display properly when zoomed and on a phone?

Then look closely at the player. Does every control have a visible or programmatic label? Is the current time and total length available as text? Can you change the playback speed or skip back a few seconds without a mouse? Does it avoid starting audio automatically, which can collide with a screen reader’s speech?

Step 6: Check on mobile

Open your site on a real phone. Are buttons large enough to tap without hitting the wrong one? Does the page work in both portrait and landscape? Turn on the phone’s built-in screen reader and try your player there, since mobile behavior often differs from desktop. Increase the system text size and see whether your page respects it.

Ask real people

Your own tests are a starting point, not a verdict. People who use assistive technology every day will notice things you can’t. Invite feedback through an obvious contact link and, if you can, ask a few listeners with disabilities to try your site and tell you what happened. Be respectful of their time. Explain what you want to test, offer payment or another fair thank-you where you can, and take their findings seriously without arguing. Their experience is the real measure.

Prioritize and re-test

After testing, you’ll have a long list. Sort it:

1. Blockers: anything that stops someone from playing the episode or reading the content, like an unreachable play button or a missing transcript. Fix these first.
2. Major barriers: low contrast, missing labels, broken heading order, content that fails at 200% zoom.
3. Minor issues: awkward wording, small inconsistencies, nice-to-have improvements.

Fix in that order, and note the date of each fix. Then set a schedule. Re-test after any change to your theme, player or layout, and run the full audit at regular intervals, perhaps twice a year for a stable site. A quick keyboard check on each new episode page takes a minute and catches many regressions.

Final thoughts

Self-testing won’t make your show perfect, but it turns vague worry into a concrete to-do list. Start with the keyboard, zoom and contrast checks, add a screen reader pass, look at your transcript and player, try your phone, and then ask real users. Fix the blockers first, keep notes, and test again. Over time, you’ll build the instincts to avoid many of these problems before they appear.