Two major accessibility deadlines have arrived in 2025 and 2026. The European Accessibility Act (EAA) took effect on June 28, 2025, requiring WCAG 2.1 Level AA compliance for digital products and services sold in the EU — with fines of up to 4% of global annual turnover for non-compliance. In the United States, the Department of Justice's ADA Title II rule requires state and local government entities serving populations of 50,000 or more to meet WCAG 2.1 Level AA by April 24, 2026. Over 4,600 ADA web accessibility lawsuits were filed in the US in 2025 alone, a number that has risen every year since 2018.

Text-to-speech is one of the most direct tools available for meeting audio accessibility requirements. This guide explains what the regulations actually require, where TTS fits in a compliance strategy, and how to implement it practically.

What the Regulations Actually Require

WCAG 2.1 Level AA is the technical standard referenced by both the EAA and the ADA Title II rule. It's organized around four principles: content must be Perceivable, Operable, Understandable, and Robust (POUR). The accessibility requirements most directly addressed by audio and TTS fall under Perceivable.

The specific success criteria relevant to audio content:

• 1.1.1 Non-text Content (Level A) — all non-text content must have a text alternative. This applies to images, icons, and controls. It's the inverse of the TTS use case, but it establishes the principle: information must be available in multiple modalities.
• 1.2.1 Audio-only and Video-only (Level A) — pre-recorded audio-only content must have a text transcript. Pre-recorded video-only content must have either a text alternative or an audio description.
• 1.2.2 Captions (Level A) — pre-recorded video with audio must have synchronized captions.
• 1.2.3 Audio Description or Media Alternative (Level A) — pre-recorded video must have an audio description or a full text alternative.
• 1.2.5 Audio Description (Level AA) — pre-recorded video must have audio descriptions for all visual information not conveyed by the audio track.

Beyond these specific criteria, WCAG 1.3.1 (Info and Relationships) and 1.3.3 (Sensory Characteristics) establish that information conveyed through visual means alone must also be available through other channels — which is the broader principle that makes audio alternatives valuable.

Who Is Affected

The scope of these regulations is broader than many organizations realize:

• EAA (EU, effective June 28, 2025) — applies to private sector businesses offering products or services in the EU, including those headquartered outside the bloc. Covers e-commerce, banking, transport, telecommunications, e-books, and computing hardware. Micro-enterprises (fewer than 10 employees and under €2M annual turnover) are exempt.
• ADA Title II (US, deadline April 24, 2026) — applies to state and local government entities serving populations of 50,000 or more. Smaller entities have until April 26, 2027. Covers websites, mobile apps, and all digital content.
• Section 508 (US federal) — applies to federal agencies and their contractors. Already references WCAG 2.0 Level AA; aligns with WCAG 2.1 in practice.
• Private sector ADA exposure — Title III of the ADA applies to places of public accommodation, and courts have increasingly interpreted this to include websites. The 4,600+ lawsuits filed in 2025 were predominantly against private businesses, not government entities.

Only 3.7% of businesses were estimated to be fully compliant with EAA requirements at the time of its June 2025 enforcement date, according to industry surveys. The compliance gap is real and the legal exposure is active.

Where Text-to-Speech Fits in Accessibility

TTS addresses accessibility from two directions:

1. Providing Audio Alternatives for Text Content

The most direct application: generating audio versions of written content so that users with visual impairments, dyslexia, or other reading difficulties can access the same information through listening. This is distinct from screen readers (which read whatever is on screen) — it's about providing a purpose-built, high-quality audio version of specific content.

Use cases include:

• Audio versions of articles, documentation, and help content
• Narrated product descriptions for e-commerce
• Audio guides for museum exhibits, wayfinding, or physical spaces
• Spoken versions of legal documents, terms of service, or policy pages
• Audio supplements for educational materials

2. Audio Descriptions for Visual Content

WCAG 1.2.5 requires audio descriptions for pre-recorded video — narration that describes visual information not conveyed by the existing audio track. TTS can generate these descriptions from written scripts, making it practical to add audio descriptions to large video libraries without the cost of re-recording with human narrators.

3. Accessible Sharing of Audio Content

When audio content is shared publicly, the sharing mechanism itself needs to be accessible. Our sharing guide covers the available options. This means the playback interface must be keyboard-navigable, screen-reader compatible, and usable without requiring a mouse or touch input.

Practical Implementation: Audio Alternatives

Adding audio alternatives to text content is more straightforward than it might seem. The basic workflow:

1. Identify the content that needs audio alternatives — prioritize high-traffic pages, critical user journeys, and content that is legally required to be accessible.
2. Write or adapt the script — audio versions of written content often benefit from minor adaptation. Headings become spoken transitions; tables need to be described verbally; links need context that makes sense when heard rather than seen.
3. Generate the audio — use a voice that matches the tone of your content. Documentation benefits from a clear, neutral voice; marketing content may benefit from something warmer.
4. Choose the right format — MP3 is the safest choice for web embedding. OGG Opus is more efficient for modern browsers. WAV is appropriate if you're editing the audio before publishing.
5. Embed with accessible controls — the audio player itself must be keyboard-accessible. Use the HTML5 <audio> element with controls, or a player that meets WCAG requirements.
6. Keep audio synchronized with content updates — when the written content changes, the audio version needs to be updated. This is where TTS has a significant advantage over human recording: regenerating audio from an updated script takes seconds.

Multilingual Accessibility

Accessibility requirements apply to content in all languages you serve. If your site or application serves users in multiple languages, audio alternatives need to be available in those languages too. TTS with 90+ language coverage makes this feasible in a way that human recording rarely is at scale.

The EAA specifically applies to products and services targeting EU consumers, which means organizations serving French, German, Spanish, Italian, Polish, and other EU-language audiences need accessible content in those languages — not just in English.

Using the API for Accessibility Workflows

For organizations with large content libraries or dynamic content that changes frequently, manual audio generation doesn't scale. The API approach (see our API tutorial for a full walkthrough):

• Trigger audio generation on content publish — when a new article or documentation page is published, automatically generate the audio version via the API.
• Idempotency keys for safe retries — if a generation request fails or times out, retry with the same idempotency key to avoid duplicate charges and duplicate audio files.
• Webhooks for completion notification — rather than polling for job completion, configure a webhook to receive notification when audio is ready, then automatically attach it to the content.
• Consistent voice across the library — use the same voice ID in every API call to ensure all audio alternatives sound consistent, regardless of when they were generated.

A minimal integration looks like this: your CMS triggers a POST to the TTS API when content is published, stores the returned job ID, polls for completion (or receives a webhook), and attaches the audio URL to the content record. The audio is then served alongside the text version.

What TTS Does Not Replace

TTS is one component of an accessibility strategy, not a complete solution. It does not replace:

• Captions for video — WCAG 1.2.2 requires synchronized captions for video content. TTS generates audio; it doesn't generate captions for existing video.
• Semantic HTML structure — screen readers depend on proper heading hierarchy, ARIA labels, and semantic markup. TTS audio alternatives don't fix underlying structural accessibility issues.
• Keyboard navigation — WCAG 2.1 requires all functionality to be operable via keyboard. This is a UI/UX concern independent of audio.
• Color contrast and visual accessibility — WCAG 1.4.3 requires sufficient contrast ratios. Audio doesn't address visual accessibility.

A complete WCAG 2.1 Level AA compliance program requires addressing all four POUR principles. TTS is a powerful tool for the Perceivable dimension, particularly for audio alternatives and audio descriptions.

The Business Case Beyond Compliance

Accessibility compliance is often framed as a cost center. The fuller picture is different. Approximately 1.3 billion people globally live with some form of disability, according to the World Health Organization. In the EU alone, roughly 101 million people have disabilities that affect how they interact with digital content. Making content accessible expands the audience that can actually use it.

Beyond disability, audio alternatives serve users in situations where reading is difficult or impossible: commuting, exercising, driving, or working in environments where screens aren't practical. The same audio content that serves a visually impaired user also serves a commuter who wants to listen to documentation on the way to work.

Search engines also index audio content metadata. Providing structured audio alternatives with proper markup can contribute to SEO, particularly as voice search and audio-first content consumption continue to grow.

Getting Started

If you're approaching accessibility compliance for the first time, a practical starting point:

1. Run an accessibility audit on your highest-traffic pages using a tool like axe, WAVE, or Lighthouse. Identify the gaps.
2. Prioritize audio-related requirements: transcripts for audio-only content, audio descriptions for video, and audio alternatives for critical text content.
3. Generate audio alternatives for your most important pages first. Test them with actual users who rely on assistive technology.
4. Build audio generation into your content publishing workflow so new content is accessible from day one, not retrofitted later.
5. Document your compliance approach. Both the EAA and ADA Title II require organizations to be able to demonstrate their accessibility efforts.

---

Try it: Generate an audio version of a page from your site and hear how it sounds. The API documentation covers how to integrate audio generation into your content publishing pipeline.