Read-Aloud Pages: Audio as Accessibility, Not an Extra

An audio version of a page used to be a premium extra. It meant a studio, a voice artist, an editor and a re-record every time a price changed. A clean read of a long page now takes minutes on an ordinary laptop, and checking it takes longer than generating it. Once the cost falls that far, audio stops being a feature you upsell and becomes an accessibility measure you can afford on the pages that carry the argument. The European Accessibility Act turns "cheap enough" into a business question, though not in the way most summaries suggest.

Who actually benefits from an audio version

The people who gain are not a niche, and they are not all blind.

• Dyslexia. Decoding printed text costs effort, and that effort competes with meaning. An audio track lets a reader hold the thread, and many read along while the voice sets the pace.
• Low vision. A screen reader already reads the page, but it is a tool you configure and learn. An audio file is a linear, paced pass that starts from one button and works the same on a phone or in a car.
• Motor impairment. Scrolling, selecting and hitting small controls is the barrier; one control that starts and stops is easier to reach than a whole article.
• Attention differences. For some people, reading needs a quiet they do not have. Listening works while walking, cooking or waiting.
• Reading in a second language. Hearing how a term, a client name or a price is pronounced makes the text less opaque.
• Commuters and drivers. The largest group by number and the least in need, and the reason audio pays for itself.

Audio does not replace a screen reader, which navigates by headings and links, or a transcript, which serves deaf and hard of hearing readers and anyone in a quiet room. It adds a channel; it does not excuse weak contrast or unlabelled buttons.

What the European Accessibility Act actually asks for

The European Accessibility Act is Directive (EU) 2019/882. It applies from 28 June 2025 to products placed on the market and services provided to consumers after that date. The list is specific: computers and operating systems, smartphones, e-readers, payment and self-service terminals, television equipment; and on the service side, electronic communications, audiovisual media access, elements of transport, consumer banking, e-books, e-commerce and the 112 emergency number. The Commission's page on the Act is the plain-language starting point; the directive text is what a lawyer will read.

Two limits matter for a company our size. Microenterprises providing services are exempt: Article 4(5) removes them from the service requirements, and Article 3(23) defines a microenterprise as one with fewer than 10 employees and a turnover or balance sheet total not exceeding EUR 2 million. The exemption covers services, not products. Article 32 also gives services until 28 June 2030 to keep using products they already used lawfully.

What the Act asks for is narrower and more useful than "publish an MP3". For services in scope, Annex I Section III requires that information about how the service works be available "via more than one sensory channel", in an understandable way, in text that can be turned into other formats. Audio is one way to add a channel. A clean page with a real transcript may cover the same clause for many readers, and audio reaches the people text cannot.

Scope depends on what you sell and to whom. E-commerce here means a service provided at a distance through a website, at a consumer's request, to conclude a consumer contract. A studio site that ends in a contact form is not a shop that takes payment. If you sell to consumers online, assume you are in scope. If you are a small B2B studio you may be outside it or exempt, but the client who commissioned the site may not be. Transposition and penalties differ by country. This is not legal advice.

Which pages deserve audio first

The test is not "is this page long" but "does someone need to understand this before they can act". That puts four kinds of page at the front.

• Service pages. What you sell, what it includes, what it costs, what happens after someone gets in touch.
• Long guides. A 2,000-word article that answers one question is what people want to hear while they do the task it describes.
• Booking and process instructions. How to book, what to prepare, how to cancel. Confusion here costs money directly.
• FAQ and pricing. Short answers read aloud are cheap, and they cover the questions that generate emails.

Leave the rest for later. A three-paragraph news item does not need a voice. Order the work by traffic multiplied by the cost of getting it wrong, not by how interesting a page is to record.

Record each language separately, with a voice that pronounces it properly.

How to produce the audio

There are four real options, and the right answer is usually a mix.

• A recorded human read. Best prosody, best names, best timing. It needs a quiet room, a microphone and a person, and every text change means a re-record. Worth it for a page that changes once a year, or for the founder's own voice on the page that introduces the studio.
• Local text to speech. A model on your own machine. Piper is the practical starting point: local neural speech, moved from its archived repository to OHF-Voice/piper1-gpl, GPL-3.0, with a command line and a Python API. Nothing leaves the machine, which matters when the text is a client's unpublished page. We built VoiceSynth Studio around this idea: one interface over several open backends, voice profiles per project, and a batch queue that stitches long text with crossfades.
• Cloud text to speech. Steady quality, no hardware, billed by the character, and your text goes to a third party. Fine for a public post; under NDA, read the data terms first.
• The browser's own voice. The Web Speech API reads a page with the voices installed on the device. Free and fileless, but the voice varies by operating system and browser, so you cannot ship a consistent asset. Good as a fallback button, poor as the published version.

Whatever produces the sound, the pipeline is the same.

• Take the text from the CMS, not the rendered page. You want the article, not the navigation and the cookie banner.
• Rewrite for the ear. Expand abbreviations, read prices as words, spell out addresses and URLs, and replace symbols such as "&" and "/" with words. A synthesizer reading "SRL" or "1.500" letter by letter is the most common failure we hear.
• Split at headings. One file per section gives you chapter markers for free and lets a listener skip ahead.
• Chunk at sentence boundaries. Long paragraphs make a model drift, and careless joins produce audible clicks; a short crossfade fixes it.
• Leave silence and even levels. About a second between sections signals a new heading, and matching loudness stops the volume jumping between articles.
• Listen to the first minute and every number. Not a sample from the middle.

How to publish it

Three routes, and they are not exclusive.

An audio element with a transcript

The default. An <audio controls> element with an MP3 source, a label that says what it is and how long it runs, and the full transcript underneath. Two details from the HTML reference matter. The element does not display WebVTT tracks on its own, so do not promise synced captions unless you add a library or a <video> element. And the content between the tags is fallback for browsers that cannot play the file, a natural place for a download link. Never autoplay: WCAG success criterion 1.4.2 requires a way to pause or stop audio that plays automatically for more than three seconds, or volume control independent of the system level.

A podcast feed

An RSS 2.0 feed with one item per audio file and an <enclosure> carrying the file URL, its length in bytes and its MIME type. The RSS specification requires all three, and the URL must be an HTTP URL. This is the route to podcast apps and offline listening. It also gives a series a home: one feed per language, not one feed with mixed languages.

Downloadable files

A plain link to the MP3, next to the transcript. It works without JavaScript, survives a player bug, and suits a page that someone prints or saves.

Whatever you choose, keep the URL stable and version it when the text changes: slug-2026-10.mp3, not a name that gets overwritten.

What quality bar to hold

Four checks before a file goes live.

• Names and terms. Client names, product names, Romanian diacritics, the studio's own name. Keep a pronunciation list per project and reuse it; a five-minute human pass beats any model here.
• Prices and dates. "De la 1.500 de lei" read as words, with the currency named, and deadlines read as a date rather than a string of digits.
• Chapter markers that match the headings. If the transcript says section three starts at 4:12, it should start at 4:12.
• Pace under speed. Many listeners play audio at 1.25x or 1.5x. Listen once at that speed; clipped pauses and artefacts show up immediately.

How to measure use without surveillance

You can answer "does anyone use it" without building a profile of anyone.

• Count file requests. Your web server or CDN already logs every request for the MP3. That gives starts per page per day, not people, which is enough to see whether the feature is alive.
• Send one anonymous event. A small POST when playback passes, say, thirty seconds, storing only the page slug and a timestamp. No cookie, no IP address, no identifier. You learn how many listens started and how many got past the intro.
• Compare with page views. The useful figure is the rate: listens divided by page views for the same page. Heavy traffic with almost no listens says something about placement, not about demand.
• Count downloads and podcast plays. A download is someone who wants the file offline, the commuter case; the podcast host's numbers are request counts too, but they show which episodes travel.
• Ask, once. A line in a reply, or a "listened or read" option in a feedback form, is worth more than a dashboard.

What not to do: fingerprinting, session recording, per-visitor listening histories. The people this feature serves have the most reason to avoid being profiled. Keep the transcript in the HTML too: search engines index text, not audio.

Where audio fits in a web project

Audio is now one more output of the same content, not a separate production. If a page already lives in a CMS, the text is the source, a model turns it into files, and the site serves them with a transcript beside them. That is a small amount of engineering plus a review habit, not a voice studio budget. If you are rebuilding a site and want accessibility treated as part of the build rather than a later audit, see web development. Our guide to local transcription with Whisper covers the reverse direction, and the git-based CMS article explains where the text would live. To talk through your own case, book a free intro call.