Why real-time TTS matters for publishers
The web has drifted toward podcasts and audio-first consumption, but most written articles still arrive as silent text. Readers without the time — or the eyesight — to read everything on a page deserve a playback option that requires nothing from the publisher beyond the content they already have.
Traditional text-to-speech widgets generate audio files in advance. That works, but it breaks the moment you publish a new piece, edit an old one, or personalise the text per reader. A real-time engine sidesteps all of that by synthesising speech on demand, from the live DOM, at the moment someone clicks play.
data-rv-skip on it, so the player steps right past it
and keeps the flow of the article intact.
The player UX
The main player sits inline above the article — a pill-shaped control strip with play/pause, speed cycling, paragraph skip controls, and a live progress bar. When you scroll past it, a compact mini-player appears in the bottom-left corner so the controls follow you down the page.
Clicking on any paragraph jumps the narration to that block — at the next paragraph boundary, to keep things predictable.
Paragraph-boundary semantics
Pause, skip forward, and skip back all take effect at the next paragraph boundary rather than cutting speech mid-sentence. This is a deliberate v1 choice: it keeps the feature plugin free of a dependency on the core library, and it avoids the subtle bugs that come with mid-utterance cancellation.
- Pause → current paragraph finishes, narration stops there.
- Skip forward → current paragraph finishes, then jumps ahead.
- Click a paragraph → same pattern, but the jump target is whichever one you clicked.
Wrap-up
If everything works, you should hear this article read top to bottom in sequence, with the active paragraph highlighted as it plays. Try changing speed mid-playback, skipping around, and scrolling to see the mini-player appear.