WCAG 2.2 and an audio version: what the standard requires, and what it does not

WCAG (the Web Content Accessibility Guidelines) is the international benchmark for web accessibility, published by the W3C. Version 2.2 dates from October 2023, and it is the version carried into the European standard EN 301 549, into most national frameworks, and into the French RGAA as it prepares its version 5. Around audio versions, one confusion keeps coming back: that offering a spoken reading of your articles somehow "earns accessibility points." It does not, and saying so clearly avoids two opposite mistakes. Here is where an audio version genuinely meets WCAG, and where it does not meet it at all.

Three levels, a logic of criteria

WCAG is organised into success criteria, each tied to a level: A (the floor), AA (the level most regulations aim at, including the European Accessibility Act and the public sector directive), and AAA (a demanding level rarely imposed on a whole site). Conformance is measured criterion by criterion on real pages, not on a general impression. That machinery of sampling and scoring we set out on the French side in our piece on the RGAA and how a conformance rate is calculated; the same principle holds for WCAG, which the RGAA derives from.

Version 2.2 added nine criteria over 2.1, mostly around navigation, focus and authentication (target size, consistent help, accessible authentication, for instance), and removed one older criterion that had become unnecessary. None of these additions touches the audio reading of content. That is the first clue: the standard does not care whether your articles are listenable, it cares whether your site is usable with assistive technology.

The one criterion that mentions audio, and why it costs you nothing

One criterion does mention audio: 1.2.1, "Audio-only and Video-only (Prerecorded)," at Level A. It requires that audio-only content be accompanied by a text alternative that conveys the same information. An article's audio version sits in the most comfortable inverse case there is: the text alternative is the article itself, present on the page. The text is the source, the audio is its spoken rendering. Criterion 1.2.1 is therefore satisfied by construction, with no extra effort, as long as the text stays present and readable next to the player.

Read this the right way round: your audio version does not need a transcript, because it is already the reading of a displayed text. That is exactly why it does not raise a score either: it fills no gap, it doubles content that is already accessible in text form.

Where audio genuinely helps, beyond the standard

If audio ticks no box, what is it for in accessibility terms? Reaching audiences the grid of criteria does not cover. People with dyslexia, for whom decoding is costly while spoken comprehension is intact, a topic we treat separately in audio and dyslexia. Older readers whose sight is fading without an assistive tool being a fit. People with low literacy, whom no technical criterion mentions. People whose first language is not the one on the page. None of these situations appears as such in WCAG, and all of them appear in the population a public site or a news outlet is meant to serve. It is a complementary register, not a conformance register, and it is already a great deal.

One common misreading to avoid: an audio version does not replace a screen reader. The two answer different needs, and we devoted a whole article to the distinction, audio version versus screen reader.

The real risk: a player that breaks criteria

Here is the point enthusiasm tends to bury. Audio does not improve your score, but a badly built player can degrade it, and on Level A criteria, the most serious ones. Three traps recur.

The first is the keyboard (criterion 2.1.1, Level A): the play and pause buttons and the progress bar must be reachable and operable without a mouse. A player driven by mouse only excludes part of the audience and fails this criterion.

The second is the accessible name of controls (criterion 4.1.2, Level A): a button with no label a screen reader can read is announced simply as "button." Every control on the player must carry an explicit name.

The third is autoplay (criterion 2.2.2, Level A): audio that starts on its own and cannot be stopped easily is a textbook accessibility problem. The right behaviour is simple: playback never starts by itself.

To those three, add contrast (criterion 1.4.3, Level AA) of the player's icons and text, often overlooked because the component is small.

The order of work that holds

Conformance first, because it is mandatory: make the site usable by keyboard and with a screen reader, fix blocking criteria before cosmetic ones, publish a dated accessibility statement. If an audio version is in place, mention it as a complementary measure and never as a conformance measure; the accessibility statement has its own rules on this. And check the player itself at integration time, not at audit time.

At WeDispatch, the player and the transcript are rendered in the page, on your own domain, with keyboard-reachable controls and playback that never starts on its own: the integration choices are described on the accessibility page. The quality of reading French aloud is a separate job, the one we detail on the French text to speech page. To judge for yourself, hear the result on one of your own articles.

Sources: WCAG 2.2, W3C, Understanding WCAG 2.2, W3C.

Read next

• An audio player in the page or in an iframe: what that choice decides
• Image captions and photo credits: what French text to speech does with them
• Footnotes and note markers: what French text to speech does with them