Hundreds of millions of people have vision impairments that make reading a screen difficult or impossible — and text-to-speech (TTS) is one of the most direct ways a website can serve them. But adding a “listen to this page” button is not the same as being accessible. This guide explains what WCAG actually requires, where TTS fits, and how to implement it so it genuinely helps.
TL;DR: WCAG requires websites to give users alternatives to purely visual content, and text-to-speech is a practical way to deliver that for articles, announcements and learning material. Success comes from accessible player controls, full keyboard operability, no autoplay surprises and testing with real assistive technology — not just bolting on a play button.
What does WCAG actually say about text-to-speech on websites?
WCAG — the Web Content Accessibility Guidelines, maintained by the W3C — does not mandate text-to-speech by name. What it does, across its perceivable, operable, understandable and robust principles, is require that content be available in more than one sensory channel. If information is conveyed only visually, users who cannot see the screen are locked out, and the site fails.
A website offering a clean, controllable audio version of its text provides exactly that: an alternative to visual presentation. Note that website TTS differs from a screen reader — the user’s own assistive tech that reads the whole interface. Your TTS feature must work with screen readers, not assume it replaces them.
WCAG has three conformance levels: A (essential baseline), AA (the level most laws target, including the EU Accessibility Act and ADA-related expectations in the US) and AAA (strictest, rarely required in full). Aim for AA — it is where legal and practical expectations converge.
Definition: Text-to-speech (TTS) is technology that converts written text into spoken audio. On websites, it appears as a “listen” player that reads page content aloud, giving users an audio alternative to reading visually.
Which WCAG success criteria relate to audio and alternatives?
Several success criteria touch what a TTS implementation must get right. You don’t need to memorize the numbers, but your developers and auditors will reference them.
| Success criterion | Level | What it requires in plain language |
|---|---|---|
| 1.1.1 Non-text Content | A | Every non-text element — including your play, pause and stop buttons — has a text alternative screen readers can announce. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | A | Prerecorded video gets an audio description or a text alternative conveying the visual information. |
| 1.2.5 Audio Description (Prerecorded) | AA | Prerecorded video content includes audio description of important visual details. |
| 1.4.2 Audio Control | A | If audio plays automatically for more than 3 seconds, users must be able to pause, stop or control its volume independently. |
| 2.2.2 Pause, Stop, Hide | A | Moving, blinking, scrolling or auto-updating content — including audio — can be paused, stopped or hidden by the user. |
| 4.1.2 Name, Role, Value | A | Custom player controls expose their name, role and state (playing, paused) to assistive technology. |
Reading this table: criteria 1.2.3 and 1.2.5 concern prerecorded video — relevant when your site embeds video with important visual content. 1.4.2 is why autoplay is dangerous: audio starting on page load without an obvious stop control fails. And 4.1.2 is where most custom players break — a pretty play button built from a div with no accessible name is invisible to screen reader users.
Definition: A success criterion is a testable requirement in WCAG. Each one has a level — A, AA or AAA — and a site “conforms at AA” only when it satisfies every applicable A and AA criterion.
Why do websites still fail accessibility for blind and low-vision users?
The gap between intention and reality usually comes down to a handful of repeated mistakes. Understanding them explains why TTS alone is never a fix — it has to sit on top of an accessible foundation.
The most common failure is unstructured content. If headings are bold text instead of real heading elements, screen readers can’t navigate and TTS can’t find a sensible reading order — TTS reads the DOM, not the visual design.
Images without text alternatives are next: decorative images should be hidden from assistive tech; informative ones need real descriptions.
Keyboard traps and mouse-only controls exclude users who can’t use a pointer. If your audio player only starts by clicking, keyboard-only users can’t use it at all.
Low contrast pushes low-vision users toward audio — fine, but only if the audio alternative works. And autoplay, popups and moving content create the hostile environment criteria like 1.4.2 and 2.2.2 exist to prevent.
The pattern: accessibility failures are structural, and TTS is a layer that amplifies whatever structure exists. Good structure plus TTS is powerful. Bad structure plus TTS is just bad structure with sound.
How does text-to-speech help people beyond screen reader users?
It is a mistake to think of website TTS as serving only blind users. The audience for spoken content is much wider, and this is part of why TTS is such a strong accessibility investment.
People with dyslexia often comprehend spoken language far better than written text. Users with low vision who don’t use full screen readers benefit from listening instead of straining. Second-language readers understand more hearing pronunciation alongside text. Older users with declining vision may never adopt a screen reader but will press a listen button.
Then situational needs: cooking with messy hands, commuting, eye fatigue after a long workday. These users aren’t disabled but benefit from the same feature — the classic “curb cut” effect, where accessibility improvements help everyone.
An accessible TTS feature isn’t a niche accommodation; it’s a content-delivery channel. Publishers adding listen options see real engagement from audiences who simply prefer audio — as audiobook-style narration opened books to new listeners.
How do you add TTS to a website without breaking accessibility?
Added badly, TTS can make a site less accessible. Here’s how to avoid that.
First, never autoplay. Audio starting without warning disorients screen reader users already listening to their own assistive tech — two streams at once is chaos. The listen control must be user-activated, every time.
Second, build from native, semantic controls — real buttons, not clickable divs. Each needs an accessible name (“Play article audio”), a proper role and an announced state. This is criterion 4.1.2, where custom players most often fail audits.
Third, make everything keyboard-operable. A user must be able to tab to the player, start and stop playback with the keyboard, and ideally adjust speed without a mouse. Test with the keyboard alone, no mouse touching the desk.
Fourth, keep reading order sane: read main content in logical order, skipping navigation, cookie banners and footer boilerplate. Designate which container holds the readable content.
Fifth, synchronize highlighting with speech — it helps users with dyslexia and low vision follow along. The highlight needs sufficient contrast and must not rely on color alone.
Sixth, respect reduced-motion preferences: don’t animate the page aggressively during playback.
Finally, ensure the TTS reads exactly the on-page text (or provide a transcript), so users who can’t use audio still have equivalent access.
What does an accessible TTS player look like?
Evaluating a TTS plugin, widget or custom build? Check it against this picture of a genuinely accessible player.
Keep controls minimal: play/pause, stop and speed adjustment as the core set; skip-forward/back by sentence for long articles.
Every control is a real button with a text label or an accessible name, reachable by keyboard, with a visible focus indicator. The player announces state changes — when playback starts, pauses or finishes — to screen readers via live regions, without spamming announcements word by word.
The player sits in a consistent location — typically near the top of the article — never covering text, opening popups or starting on its own.
Offer speed control around 0.75x to 2x in clear steps — many spoken-content users listen faster than 1x, some need it slower.
The current sentence is highlighted with strong contrast, the player itself meets contrast requirements, text stays resizable, and nothing depends on color alone.
Demo any vendor player with keyboard and a free screen reader before buying — five minutes reveals what sales pages hide.
How do you test your website’s audio accessibility?
Testing is where accessibility claims get verified, and it needs more than an automated scan — automated checkers catch perhaps a third of real issues.
Start manual: unplug the mouse and operate the TTS feature by keyboard — reach the player, start playback, change speed, stop. Then test with a real screen reader (NVDA is free on Windows; VoiceOver is built into Apple devices): do buttons have names, are state changes announced, does reading order make sense?
Check the failure modes: what happens when audio cannot load, when JavaScript is disabled, when the user is on a slow connection? The page must remain fully usable — the TTS is an enhancement, not a dependency.
Test with real users when you can — thirty minutes with an experienced screen reader user teaches more than a week of checklist reading.
Re-test after every redesign — a new theme can silently break the reading container or restyle buttons into inaccessible divs. Add the player to your regression checklist. Teams producing online course audio or e-learning narration should apply the same discipline.
What does WCAG 2.2 change for accessible audio?
WCAG 2.2 is the current W3C recommendation. It didn’t rewrite the audio criteria, but refined surrounding requirements TTS implementers should know.
The headline change is new success criteria, mostly at level A and AA, tightening focus visibility, pointer interaction and form assistance. For audio features, the most relevant is the strengthened focus-appearance guidance: your player’s keyboard focus indicator must now be clearly visible against adjacent colors, not just present. If your play button’s focus ring was a subtle outline that barely shows, 2.2-era audits will flag it.
2.2 removed one obsolete criterion (4.1.1 Parsing) and added nine new ones — none targeting TTS specifically. The message: the existing audio criteria are sufficient; the work is in implementation quality, not new rules.
Practically: if your TTS player conforms to the long-standing criteria in the table above and meets the sharper focus-visibility expectations of 2.2, you are in good shape. Don’t chase the version number; chase the user experience.
What mistakes make website TTS less accessible?
The failures auditors see most often: autoplaying audio (fails 1.4.2, collides with screen readers); custom controls without accessible names (fails 4.1.2); reading the wrong content because the readable region was never defined; no keyboard support; missing speed control; poor highlight contrast. And the most expensive mistake — treating TTS as a substitute for real accessibility, slapping a listen button on an unstructured page and declaring victory.
There’s also the voice-quality trap: robotic or badly paced audio gets abandoned. Natural voices with correct pronunciation of your domain’s terminology decide whether people actually use the feature — announcement-style TTS shows how far intelligibility has come. Tools like SynVoice.io offer natural-sounding TTS voices suited to accessible page audio, though any quality neural TTS with good pronunciation control will serve.
Accessibility implementation checklist
Use this numbered checklist when adding or auditing TTS on your site. Every item should be a yes before you ship.
- Playback never starts automatically; the user always initiates it.
- All player controls are native buttons with accessible names, roles and announced states.
- The full workflow — play, pause, stop, speed change — works by keyboard alone, with a clearly visible focus indicator.
- A defined content region is read in logical order; navigation, ads and boilerplate are excluded.
- Spoken-word highlighting follows playback with sufficient contrast and does not rely on color alone.
- Speed can be adjusted across a useful range (around 0.75x to 2x).
- State changes (playing, paused, finished, error) are announced to screen readers via live regions.
- The page remains fully usable if the audio fails to load or JavaScript is unavailable.
- The feature has been tested with at least one real screen reader and keyboard-only navigation.
- Underlying page structure is sound: real headings, text alternatives for images, and sufficient contrast — TTS enhances access, it does not create it.
FAQs
Does WCAG require websites to have text-to-speech?
No — WCAG never names text-to-speech. It requires content to be perceivable through more than one sense, with criteria for alternatives to visual and audio content. TTS is one practical way to meet that spirit, but conformance is judged on the criteria, not the technology.
What WCAG level should I target for my website’s audio features?
Level AA — the target of most accessibility laws worldwide, including the European Accessibility Act and ADA-related expectations in the US. Meeting all applicable A and AA criteria gives the strongest practical and legal position.
Will adding a listen button make my site WCAG compliant?
No. A TTS button doesn’t fix missing headings, unlabeled controls, keyboard traps or contrast failures — and a badly built player adds new violations. TTS is one layer of a program that starts with semantic HTML and keyboard support.
Should my TTS audio autoplay when the page loads?
Never. Beyond failing WCAG 1.4.2, autoplay collides with screen readers and disorients users. Always let the visitor press play.
How is website TTS different from a screen reader?
A screen reader is the user’s assistive tech reading the whole interface. Website TTS is a feature you add that reads your content aloud on demand. It must work alongside screen readers — never replacing or interfering with them.
What is the biggest technical mistake in TTS player design?
Building controls from non-semantic elements — clickable divs styled as buttons — without accessible names, roles or states. Use native button elements and verify with a screen reader.
How often should I re-test my site’s TTS accessibility?
After every template, theme or player update, plus at least annually — content and code drift. Keep the player on the same regression checklist as forms and navigation.