Text to Speech Accessibility: WCAG Guide for 2026

Text to speech accessibility is narrower than many site owners expect. Adding a read-aloud widget does not make a website WCAG compliant. WCAG judges the whole page, including structure, contrast, labels and language. Text to speech is one aid, and screen readers do considerably more. This is general information, not legal advice.

This guide explains where text to speech fits, which WCAG 2.2 criteria apply to audio, what the 2026 laws say, why compliance claims for overlays have drawn regulator action, and how to publish audio the right way.

Does text to speech make a website accessible?

No, not by itself. Text to speech reads text aloud. Accessibility depends on whether people can perceive and operate everything on the page, and that depends on the markup, the colour contrast, the form labels, the headings and the language declaration. A read-aloud tool can help a reader with some content, but it cannot repair those parts of a page.

The same point appears in the data. WebAIM's Million 2026 report found that 95.9% of home pages had detected WCAG 2 failures. The most common were low-contrast text (83.9%) and missing alternative text (53.1%). A read-aloud widget does not fix either problem.

Text to speech vs screen reader: what is the difference?

People often treat the two as the same thing. They are not. The table compares them in general terms.

| Feature | Text to speech | Screen reader | |---|---|---| | Main job | Reads text aloud | Lets people navigate and operate a device, page, form and menu by ear and keyboard | | Typical examples | Read-aloud features in browsers, operating systems and apps | JAWS, NVDA, VoiceOver, Narrator, ChromeVox, Orca | | Use for forms and menus | Not its purpose | Core purpose | | Depends on page markup | Partly, for text content | Heavily, for headings, labels, roles and language |

The EU's Your Europe guidance says products and services should work with assistive technologies such as screen readers and voice control. That is the standard to design for, not a read-aloud button.

Which WCAG 2.2 criteria apply to audio and spoken content?

WCAG 2.2 became a W3C Recommendation on 5 October 2023 and was updated on 12 December 2024. It adds nine success criteria to WCAG 2.1 and marks 4.1.1 Parsing as obsolete. It was approved as ISO/IEC 40500:2025, announced on 21 October 2025. WCAG 3 is an early draft, not a published standard.

The criteria below matter most for audio and spoken content. Read the full WCAG 2.2 text for exact wording.

| Criterion | Level | Plain meaning for TTS and audio | |---|---|---| | 1.1.1 Non-text Content | A | Non-text content needs a text alternative that serves the same purpose | | 1.2.1 Audio-only (Prerecorded) | A | A transcript or similar alternative must present equivalent information | | 1.2.2 Captions (Prerecorded) | A | Prerecorded audio in synchronized media needs captions | | 1.4.2 Audio Control | A | Audio that plays automatically for more than 3 seconds needs pause, stop or separate volume control | | 1.4.7 Low or No Background Audio | AAA | Prerecorded speech with little or no background sound | | 3.1.1 Language of Page | A | A declared page language lets screen readers load pronunciation rules | | 3.1.6 Pronunciation | AAA | A way to identify the specific pronunciation of a word where meaning is ambiguous |

The audio control criterion explains why autoplay is a problem. Screen reader speech is hard to hear over other sound, and autoplaying audio can interfere with navigation. Start audio on a user action.

What the laws say in 2026

Standards and laws use WCAG as their base, but they apply to different organisations and have different dates. The table summarises the sources.

| Law or standard | Applies to | Requirement | Key date | |---|---|---|---| | WCAG 2.2 | Technical standard. The laws below name specific WCAG versions | Success criteria at Levels A, AA and AAA | 5 October 2023; updated 12 December 2024 | | ADA Title II web rule | US state and local governments, including public schools, community colleges and public universities | WCAG 2.1 Level AA | Rule published 24 April 2024; interim rule published 20 April 2026; compliance 26 April 2027 (50,000 or more people) or 26 April 2028 (smaller entities and special districts) | | Section 508 | US federal agencies, for electronic content and software | WCAG 2.0 Level A and AA | Final rule 18 January 2017 | | European Accessibility Act | Products and services placed on the EU market, including online shops, ticketing platforms and banking services | Products and services should work with assistive technologies such as screen readers and voice control | Applies to products and services placed on the market after 28 June 2025 |

Older articles may still give the 24 April 2026 or 26 April 2026 dates for the ADA rule. Those are superseded by the April 2026 interim final rule. Whether a particular site falls under a law is a legal question, so check with your institution or a qualified adviser. This is general information, not legal advice.

Why overlays and one-click compliance claims are risky

An accessibility overlay is a script added to a site that offers adjustments, often sold as a way to make a site compliant. The US Federal Trade Commission has acted on this claim. On 22 April 2025 it announced approval of a final order requiring accessiBe to pay $1 million. The FTC alleged that accessiBe's accessWidget did not make all websites WCAG-compliant and that its claims were false, misleading or unsubstantiated. It also alleged that reviews and articles were presented as independent without disclosing material connections.

The order bars accessiBe from claiming that its automated products can make any website WCAG-compliant or keep it compliant, unless it has evidence. It applies to accessiBe, not to every overlay vendor. The lesson for any site owner is simple: treat a tool that promises compliance by itself with suspicion, and ask for evidence.

How to publish audio the right way

If you add audio versions of articles, lessons or announcements, follow these steps.

1. Publish a transcript next to every audio file. For recordings with several speakers, identify who is speaking and note significant sounds.
2. Start playback when a visitor presses play. Do not autoplay.
3. Provide a visible pause or stop control, and make sure it works from the keyboard.
4. Declare the page language so screen readers load the right pronunciation rules.
5. Write plain-language text before you convert it, because a voice reads exactly what it is given.
6. Test with real assistive technology and with people who use it, not only with an automated checker.

When you test, know which tools your visitors use. WebAIM's Screen Reader User Survey #11, run in July and August 2026 with 1,780 valid responses, reports these desktop screen readers in common use:

| Screen reader | Used on desktop (share of respondents) | Primary desktop screen reader (share) | |---|---|---| | JAWS | 69.2% | 55.0% | | NVDA | 59.3% | 32.9% | | VoiceOver | 42.0% | 6.5% | | Narrator | 36.1% | Not listed in the results summarised |

The survey does not report text to speech usage or speech rates, so use it to choose what to test, not to size a market.

Where OndaLabs fits

OndaLabs is an AI voice studio. It can produce audio versions of articles, lessons or announcements. Those audio files can sit on a page next to a transcript:

• Text to speech with 30 prebuilt voices, usable in every supported language, and 37 language pages. See text to speech to get started.
• Speech to text at 50 credits per minute, which can draft a transcript from audio you already have. A person must review it, in the speech to text tool.
• Commercial use is included from the Starter plan at $9 a month. Plans are on the pricing page.

OndaLabs does not make a site accessible. The accessibility of a page still depends on its markup, its contrast, its forms and its language settings, which sit outside OndaLabs. OndaLabs is not an overlay, and it does not provide compliance certification.

For classroom use, read text to speech for e-learning and read aloud tools for students.

Frequently asked questions

Does adding text to speech make my website WCAG compliant?

No. WCAG covers the whole page, including structure, contrast, labels, keyboard use and language. A read-aloud feature helps with some text, but it does not satisfy the criteria for the rest of the page. Test the site with assistive technology and fix the markup.

Is text to speech the same as a screen reader?

No. Text to speech reads text aloud. A screen reader lets a person navigate and operate a device, page, form and menu by ear and keyboard. Screen reader users depend on correct markup, headings and labels.

Do I need a transcript for an AI-generated audio file?

Generally yes. WCAG 1.2.1 requires an alternative for audio-only content, and a transcript is the usual example. The transcript should present the same information as the audio, and identify speakers where that matters. A person should check the transcript before you publish it.

What is the ADA Title II web accessibility deadline now?

For US state and local governments, the rule requires WCAG 2.1 Level AA. After the interim final rule published on 20 April 2026, compliance is due 26 April 2027 for governments serving 50,000 or more people, and 26 April 2028 for smaller governments and special districts. Check how your institution applies the rule, because older articles show different dates.

Does the European Accessibility Act apply to my website?

It depends on what your site offers and where you sell. The Act applies to products and services placed on the EU market after 28 June 2025, and the EU's guidance names online shops, ticketing platforms and banking services among them. Exemptions exist for some small businesses and for disproportionate burden. Check the official guidance or an adviser before you rely on one.

Are accessibility overlays a safe shortcut?

Not as a claim of compliance. The FTC's 2025 order against accessiBe barred unsupported claims that its automated product could make any website WCAG-compliant. Use overlays, if at all, as one input alongside real testing and fixes to the page itself.