The web is about to start talking

For thirty years a web page has been a thing you look at, in one language, silently.

All three of those assumptions are expiring at the same time, and the studios that treat them as optional extras are about to find themselves shipping the 2019 version of a website at 2026 prices.

Part one: one language stops being a default

Publishing in another language means writing or translation, then review, implementation, and maintenance. Better tools can cut the drafting effort. The complete service still takes work.

As those tools improve, we expect more businesses to offer more than one way to read and to listen. The right scope depends on what customers need and on whether the team can answer them in each language.

Localization starts with the audience

Professional translation and original writing can both work well. Either way, check the terminology, tone, examples, and practical information against the reader you're writing for. Sometimes the same service information belongs in both versions. Sometimes the audience needs different content.

Getting that editorial call right matters more than claiming every second language is free, or that translated content can't perform. Our bilingual guide explains how we plan it.

What that looks like in practice

This month we shipped Rounds, a daily news briefing with an English edition and a Spanish one. The Spanish edition isn't the English page in Spanish. Almost nothing crosses over.

That last row is the whole argument in one word. A translation engine turns "Wire" into Cable. A Spanish newsroom calls it el teletipo. One of those is a translation and the other is the language.

And the history module is the tell. On the same August morning, the English edition surfaced a Colorado mine spill, while the Spanish edition surfaced a Spanish Civil War naval convoy and the death of Friedrich Engels. The feature and the date were the same. The past wasn't. What a culture remembers about a date is content, and no translation layer can generate it.

A translated site hands a Spanish reader an American morning in Spanish. That's a different product, and they can tell.

Part two: pages will read themselves

The second default is louder, in the literal sense.

Every major browser has shipped a speech synthesis API for years. Almost nobody used it, because the voices were terrible. They mispronounced words and sounded so flat and robotic that listening took more work than reading. So read-aloud stayed where people put up with bad voices because the alternative is nothing: assistive technology.

Neural voices fixed the quality problem. The reason nobody shipped read-aloud has quietly stopped being true, and the demand it was failing to serve was never small. People already listen to an enormous amount of text: podcasts, audiobooks, saved-article apps, screen readers, the read-aloud built into every phone. The listening habit is already there. The page just wasn't taking part.

You are already being read aloud

This is the argument that should actually move you.

Ask an assistant about your business today and it reads your page out loud, in a synthetic voice you didn't choose, with your product names pronounced however the model guesses, at a pace you didn't set, and with your structure flattened into whatever the model thought was important.

AI search is one more place where customers may come across your information. How far it reaches varies by audience and by query, so judge your own site by actual visibility and inquiry measures.

You can't opt out of being read aloud. The only choice you get is whether the voice doing it is yours.

What has to be true first

Read-aloud isn't a widget you bolt on. Turn TTS loose on a typical page and it will earnestly recite the skip link, the cookie banner, the nav, "Home Services About Contact", every icon with a missing label, and then, finally, the article. That's worse than silence. It's also exactly why the first wave of read-aloud buttons got ignored.

The page has to be built so a voice can move through it:

• Real semantic structure. <main>, <nav>, <article>, headings in order and not chosen for size. A voice has no peripheral vision, so heading order is the layout.
• A correct lang attribute, and lang on foreign phrases inside the text. It's the same hook that makes a page multilingual and the one that makes it pronounceable. A Spanish name inside an English sentence is either marked up or mangled.
• Alt text that reads as a sentence, because it will be read as one.
• Abbreviations and numbers that survive being spoken. "$1.2M" and "e.g." are visual shorthand. Out loud, they're a stumble.
• No content that only exists in a layout. Anything carried by position, colour, or a hover state doesn't exist to a listener.

Nothing on that list is new. It's the same discipline that has always served screen readers, and it's close to identical to what makes a page extractable by an AI engine. One investment, three payoffs: accessibility, voice, and citation. They rarely line up this cleanly, which is a good reason to stop treating any of the three as a compliance chore.

Where the voice should not go

We're not neutral about this, and we've already turned it down once.

Cuyar is our movement app for adults over 65, and it talks constantly: nine coach voices guide people through the exercises. We evaluated browser text-to-speech for it and rejected it. The cadence is wrong for instruction, it degrades unpredictably across devices, and it can't be relied on offline. Every voice line in that app is a pre-generated audio clip shipped with the product.

That decision holds, and it draws the line precisely.

Narration tolerates error. Instruction does not. If a voice misreads a comma while reading you a news brief, you lose a beat. If it misreads a pause while telling a 78-year-old how to lower themselves into a chair, that's a fall. Synthetic narration will become a default for articles, briefings, documentation, and product copy long before it should be trusted anywhere a wrong syllable has a physical consequence.

The web is going to start talking. That doesn't mean every page should say everything out loud.

The short version

1. Pick your languages by what customers need and what you can maintain. Review each language as part of the whole service, contact experience included.
2. Localisation is a content decision. The sources change, and so do the examples and the references. Same words in a different language is the cheap version, and it reads that way.
3. Machines you don't control are already reading your page aloud. Shipping your own voice layer is how you take that back.
4. The work that makes a page speakable is the work that makes it accessible and citable. Do it once.

None of this is a prediction about some distant web. Two of the four are true today, and the other two are a build cycle away.

We build bilingual sites where the Spanish is written, not translated, and you can see how we do it or look at Rounds, where the two editions don't share a single source.