EAA Voice Guide: TTS Compliance Under the EAA

Synthesized audio that works for hearing users fails entirely for people with auditory processing disorders, vision impairments, or motor limitations that prevent mouse interaction. The European Accessibility Act (EAA) made this a legal problem on June 28, 2025.¹ Any digital service reaching EU consumers that uses TTS now faces specific, enforceable requirements for how that audio is delivered, controlled, and sourced. This guide covers what those requirements are, how to meet them, and what happens to organizations that do not.

Who must comply

The EAA applies to any organization that places products or provides services on the EU market, regardless of where that organization is headquartered.¹ The scope targets specific product and service categories.

Covered sectors

Who is exempt

Micro-enterprises are the only categorical exemption. Every other organization providing covered services to EU consumers must comply. This includes non-EU companies selling into the EU market.

What the EAA requires for audio content

The EAA references the EN 301 549 standard, which maps to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as the baseline.³ Organizations targeting compliance should plan for WCAG 2.2 Level AA, published in October 2023,⁴ as this reflects current best practice and anticipated regulatory updates.

The enforcement mechanism varies by member state. Penalties include fines up to 900,000 EUR in the Netherlands, criminal liability in Ireland, and daily compulsory fines in Norway. As of March 2026, enforcement activity has begun across member states, with Germany, France, and the Netherlands among the first to take action.

The six WCAG criteria that apply to TTS

WCAG compliance for TTS has six critical requirements and two that depend on context. Getting any of these wrong creates a specific, documentable compliance failure.

1.4.2 Audio Control (Level A). Any audio that plays automatically for more than three seconds must have a mechanism to pause, stop, or control volume independently of the system volume. TTS implementations that auto-play content without providing these controls are non-compliant. The control mechanism must appear before the audio element in the page.

1.2.1 Audio-only (Level A). Pre-recorded audio requires a text alternative. For TTS, this means the source text must remain available alongside the audio. The text already exists, but the design must ensure it is discoverable and associated with the audio output.

1.3.1 Info and Relationships (Level A). The link between text content and its audio equivalent must be programmatically determinable. A “listen to this article” button must be associated with the article it reads. Screen reader users must understand which audio player corresponds to which text content.

4.1.2 Name, Role, Value (Level A). Every audio player control must have an accessible name, correct ARIA role, and expose its current state. A play/pause button must announce itself correctly to a screen reader. A volume slider must communicate its current value.

2.1.1 Keyboard (Level A). All audio player functionality must be operable through keyboard alone. Play, pause, stop, volume, and playback rate controls must all be reachable and activatable without a mouse. Focus order must be logical and visible.

3.1.1 and 3.1.2 Language (Level A and AA). The lang attribute on the HTML element and on specific content sections tells both screen readers and TTS engines which language model to use. Missing or incorrect language tags produce garbled pronunciation. This is the single most common compliance failure in multilingual TTS deployments.

What compliance looks like in practice

Six technical requirements translate the WCAG criteria into implementation decisions. Each one maps to a specific failure mode observed in production deployments.

Language declaration is mandatory. Every page with TTS output must have a correct lang attribute on the html element. Content sections in different languages must use lang attributes on their container elements. Omitting language tags is the single most common accessibility failure in multilingual TTS deployments.

For multilingual content, SSML lang tags tell the TTS engine which pronunciation model to apply:

<speak>
  <p>The regulation is officially titled
    <lang xml:lang="fr-FR">Loi pour l'accessibilite numerique</lang>
    in French law.</p>
  <p>In German, it is the
    <lang xml:lang="de-DE">Barrierefreiheitsstaerkungsgesetz</lang>.</p>
</speak>

Without these tags, a TTS engine applies English phonology to French and German words, producing unintelligible output.

Audio must never auto-play. Require an explicit user action before any audio begins. If auto-play is unavoidable, provide a pause/stop mechanism that appears before the audio element in the DOM and is keyboard accessible. Avoiding auto-play entirely is both simpler and more compliant.

Users must control playback speed. A playback rate control (typically 0.5x to 2x) allows users to consume audio at their preferred pace. Accessibility auditors evaluating EAA compliance consider this best practice.

Users should choose a voice. Offering a choice between voices improves usability for people with auditory processing differences. Even two options is better than none.

Source text must remain available. Since TTS is generated from text, the source text itself serves as the transcript. The text and audio must be clearly associated, and users who cannot access the audio must find the text equivalent without difficulty.

The audio player must be keyboard accessible. Every control must be reachable via tab, activatable via Enter or Space, and visually distinguishable when focused. Custom players built with div elements instead of semantic HTML fail this requirement consistently.

A minimal compliant audio player skeleton using semantic HTML and ARIA:

<div role="region" aria-label="Audio player for Article Title">
  <audio id="tts-audio" src="article-audio.mp3" preload="none"></audio>
  <button aria-label="Play" aria-pressed="false"
          onclick="togglePlay()">Play</button>
  <button aria-label="Stop" onclick="stopAudio()">Stop</button>
  <label for="volume">Volume</label>
  <input id="volume" type="range" min="0" max="100" value="80"
         role="slider" aria-valuemin="0" aria-valuemax="100"
         aria-valuenow="80" aria-valuetext="80 percent">
  <label for="speed">Speed</label>
  <select id="speed" aria-label="Playback speed">
    <option value="0.5">0.5x</option>
    <option value="0.75">0.75x</option>
    <option value="1" selected>1x</option>
    <option value="1.25">1.25x</option>
    <option value="1.5">1.5x</option>
    <option value="2">2x</option>
  </select>
  <div aria-live="polite" class="sr-only"></div>
</div>

This uses native <button>, <input>, and <select> elements rather than styled div elements, providing keyboard support and screen reader compatibility without additional JavaScript.

Choosing a TTS provider for regulated deployments

Provider selection for EAA-regulated contexts involves compliance, data handling, and pronunciation control. Technical quality alone is not sufficient.

GDPR compliance is a prerequisite. The General Data Protection Regulation (GDPR) applies to any processing of personal data of EU residents. Text submitted to a TTS API may contain personal data: names, addresses, medical information, financial details. The provider must offer a signed DPA (Data Processing Agreement), disclose all sub-processors, and provide clear documentation of data handling practices.

Data processing location matters. Some providers process all requests in the United States with no option for EU-based processing. If text content contains personal data, processing outside the EU requires additional safeguards under GDPR Chapter V. The simplest path: choose a provider that offers EU data residency.

Data retention policies must be explicit. Verify whether the provider retains submitted text, generated audio, or metadata after synthesis. Providers that retain data for model training create additional GDPR obligations. The cleanest approach for regulated use cases: a provider that deletes all data immediately after synthesis.

SSML support enables pronunciation compliance. SSML (Speech Synthesis Markup Language) provides the mechanism for pronunciation control. At minimum, the provider must support lang for language switching, phoneme for pronunciation overrides, and break for pause control. These features are not optional for multilingual content or specialized domains.

Building a compliant audio player

The audio player is where most EAA compliance failures occur. A technically correct TTS integration paired with an inaccessible player negates the accessibility benefit entirely.

Start with the HTML audio element. The native element provides built-in keyboard support, screen reader compatibility, and standard controls. Build custom controls on top of it rather than replacing it. Hide the native controls visually but keep the audio element in the DOM for assistive technologies.

Required controls:

1. Play/pause toggle with clear visual state indication
2. Stop button that resets playback to the beginning
3. Volume control with mute option
4. Playback rate selector (0.5x, 0.75x, 1x, 1.25x, 1.5x, 2x)
5. Progress indicator showing current position and total duration
6. Skip forward/backward by a configurable interval (10 or 15 seconds)

Keyboard interaction:

• Tab moves focus between controls in a logical order
• Enter and Space activate the focused control
• Arrow keys adjust sliders (volume, progress, playback rate)
• Escape closes expanded menus
• Focus indicator meets the 3:1 contrast ratio against adjacent colors

ARIA requirements:

• Each button has an aria-label describing its function (“Play article audio”, “Pause”, “Increase playback speed”)
• Toggle buttons use aria-pressed to communicate state
• Sliders use role="slider" with aria-valuemin, aria-valuemax, aria-valuenow, and aria-valuetext
• The player region has role="region" with an aria-label (“Audio player for article title”)
• Live regions announce state changes (“Playing”, “Paused”, “Playback speed set to 1.5x”)

Screen reader testing is not optional. Test with NVDA on Windows and VoiceOver on macOS at minimum. Verify that every control announces its name, role, and state correctly. Automated testing catches roughly 30 to 40 percent of accessibility issues (Deque, 2023).⁵ Manual screen reader testing catches the rest.

Seven mistakes that fail EAA audits

Each of these mistakes is observed in production TTS deployments as of March 2026. Each one creates a specific, documentable compliance failure.

Hardcoded voice with no user control. Selecting a single voice and providing no mechanism to change it ignores users with auditory processing disorders who find certain voice characteristics difficult to understand. The fix: store voice preference per user and expose a voice selection interface.

Missing language tags. A page in English that includes a French quotation will be synthesized entirely in English if no lang="fr" attribute marks the French section. The TTS engine applies English phonology to French words, producing unintelligible output. The fix: audit all content for language boundaries and add lang attributes at the paragraph or span level.

No fallback when TTS is unavailable. If the TTS API is unreachable and the audio player shows an error with no alternative, audio-dependent users are blocked. The fix: keep the source text visible. The player should degrade gracefully to a message indicating audio is temporarily unavailable. TTFB monitoring helps detect service degradation before users are affected.

Auto-play without consent. Playing audio on page load violates WCAG 1.4.2 and interrupts screen reader output. The fix: require explicit user action to start playback.

div-based audio player. A player built from styled div elements with click handlers is invisible to screen readers and inoperable by keyboard. The fix: use button and input type="range" for all interactive controls.

No pause or stop control. Some implementations provide a play button but no way to pause. The fix: provide pause, stop, and volume controls that are keyboard accessible and appear before the audio content in the DOM.

Low contrast on player controls. Audio player buttons and text below 4.5:1 contrast ratio for normal text or 3:1 for large text are inaccessible to users with low vision. The fix: verify all player UI elements against WCAG contrast requirements.

TTS pricing and licensing for accessibility at scale

Two practical considerations determine whether an accessibility-focused TTS deployment is financially sustainable: the pricing model and the audio caching rights.

Cost at accessibility scale

Accessibility use cases generate high character volumes. A news site with 500 articles averaging 5,000 characters each produces 2.5 million characters of TTS content. A government portal with thousands of pages reaches tens of millions. At these volumes, pricing model choice has a larger impact than per-unit cost differences.

ElevenLabs uses a credit-based pricing model where 1 credit equals 1 character for standard models. Effective cost per million characters ranges from approximately $120 (Business plan, 11M credits at $1,320/month) to $198 (Pro plan, 500K credits at $99/month) as of March 2026. For pre-rendered accessibility audio, the cost difference between providers ranges from $10 to $500 for the same 2.5 million characters. At scale, this difference determines whether TTS accessibility is operationally viable.

Audio caching rights

Caching is critical for accessibility performance. Pre-rendering TTS audio and serving it from a CDN eliminates latency entirely, providing instant playback.

Amazon Polly, Google Cloud TTS, and Azure AI Speech explicitly allow unlimited storage and reuse of generated audio files.⁶⁷⁸ Pre-render the entire content library and serve cached audio without additional API costs.

Review provider terms of service before implementing a caching strategy. The key clause: whether generated audio files can be stored and served from your own infrastructure without per-play fees.

Evolving regulations

The regulatory landscape is not static. Several developments will affect TTS compliance requirements in the coming years.

EN 301 549 updates. The current version (V3.2.1, published 2021)³ maps to WCAG 2.1 AA. Future updates are expected to incorporate WCAG 2.2 requirements and may add TTS-specific provisions. Monitor updates from ETSI and CEN/CENELEC.

National transposition differences. Germany’s BFSG and France’s transposition have different enforcement mechanisms and penalty structures. Organizations operating across multiple EU markets should track national implementations individually.

WCAG 3.0. The W3C is developing WCAG 3.0 (working draft as of March 2026), which introduces a scoring model rather than pass/fail criteria at A, AA, and AAA levels. Adoption is years away, but the direction informs architectural decisions today.

The EU AI Act. Regulation 2024/1689⁹ introduces transparency obligations for synthetic media. If TTS output could be mistaken for human speech, disclosure requirements apply. The AI Act’s provisions are phasing in between 2025 and 2027.¹⁰ Voice cloning capabilities make this especially relevant for personalized voice applications.

Review cadence. Audit TTS implementations against current WCAG criteria annually. Review provider compliance documentation every six months or at contract renewal.

Accessibility compliance is not a one-time project. It is an ongoing operational requirement. Building TTS implementation with compliance as a design constraint rather than a retrofit produces better outcomes, lower maintenance costs, and a product that serves all users. The EAA enforcement date has passed.

Frequently asked questions

What is the European Accessibility Act and when did it take effect?

The European Accessibility Act (EAA) is EU Directive 2019/882. It became enforceable on June 28, 2025. It requires organizations that place products or provide services on the EU market to meet specific accessibility standards for digital products and services, including text-to-speech implementations.

Who must comply with the EAA?

Any organization providing products or services to EU consumers must comply, regardless of where the organization is headquartered. The only categorical exemption is micro-enterprises with fewer than 10 employees and annual turnover under 2 million EUR.

Which WCAG criteria apply to TTS implementations?

Six critical criteria apply: Audio Control (1.4.2), Audio-only alternatives (1.2.1), Info and Relationships (1.3.1), Name/Role/Value (4.1.2), Keyboard accessibility (2.1.1), and Language specification (3.1.1 and 3.1.2). All are Level A except Language of Parts, which is Level AA.

What are the most common EAA compliance failures in TTS?

Seven failures appear consistently: hardcoded voice with no user control, missing language tags on multilingual content, no fallback when TTS is unavailable, auto-play without consent, div-based players instead of semantic HTML, missing pause/stop controls, and low contrast player controls.

How much does TTS cost for accessibility at scale?

Costs range from $4 per million characters (Amazon Polly Standard, Google Cloud TTS Standard) to approximately $120 to $200 per million characters (ElevenLabs, depending on plan tier) as of March 2026. Amazon Polly, Google Cloud TTS, and Azure AI Speech all allow unlimited audio caching.

What are the penalties for EAA non-compliance?

Penalties vary by country: up to 900,000 EUR in the Netherlands, 300,000 EUR in Spain, 250,000 EUR in France, 100,000 EUR in Germany, and daily compulsory fines in Norway. Ireland is the only EU state with criminal penalties, including up to 18 months imprisonment.

Which companies have already been taken to court under the EAA?

As of March 2026, four French retailers (Auchan, Carrefour, E. Leclerc, Picard Surgeles) face the first private-sector EAA lawsuits, filed in November 2025. Vueling Airlines was fined 90,000 EUR in Spain under pre-EAA accessibility law. Norway has placed six healthcare organizations under regulatory supervision.

Does the EAA apply to non-EU companies?

Yes. The EAA applies to any organization that places products or provides services on the EU market, regardless of where the organization is headquartered. A US company selling digital services to EU consumers must comply.

Bonus: EAA enforcement tracker, who is already in court

The EAA became enforceable on June 28, 2025. Nine months later, enforcement is already active across multiple member states. No final EAA verdict has been issued as of March 2026, but companies are in court, daily fines have been threatened, and national authorities are conducting audits.

Companies in active court proceedings

In November 2025, disability rights organizations ApiDV and Droit Pluriel filed emergency injunctions against four major French retailers, citing inaccessible online grocery shopping platforms.¹¹ These are the first private-sector lawsuits filed under the EAA anywhere in Europe. Verdicts are expected in April 2026.

Companies fined or under regulatory action

Norway’s Uu-tilsynet (Directorate for Universal Design of ICT) inspected HelsaMi, a patient portal used by 425,000 residents in Mid-Norway, and found 119 accessibility errors across 12 of 14 legal requirements.¹⁴ After the remediation deadline passed with 64 issues unresolved, the authority issued a compulsory fine order of NOK 50,000 per day (approximately 4,700 EUR per day). Helseplattformen corrected all remaining errors four days before the fines would have started.

Germany: mass cease-and-desist wave

Since August 2025, law firm CLAIM Rechtsanwalte has sent mass cease-and-desist letters (Abmahnungen) to dozens of small and medium-sized German online shops, alleging violations of the BFSG (Barrierefreiheitsstaerkungsgesetz, Germany’s EAA transposition).¹⁶ The letters demand settlements of 600 to 1,000 EUR each. Legal experts have questioned the validity of these warnings, noting they contain only screenshots as evidence with no specific violations named.¹⁶ German market surveillance authorities have not issued formal enforcement actions of their own as of March 2026.

National enforcement programs underway

Seven countries have active enforcement or audit programs as of March 2026:

EU infringement proceedings

The European Commission is acting against member states that have not properly transposed the EAA:

• Bulgaria was referred to the European Court of Justice in July 2024 for failing to transpose the directive entirely.¹⁷
• Germany received a supplementary reasoned opinion in March 2026 for incomplete transposition, with a deadline of mid-May 2026.¹⁷

Maximum penalties by country