Text to speech is the conversion of written text into a synthesized voice. It is one output of a screen reader and it is not a screen reader, which is the distinction that settles most arguments about it. W3C defines the two separately. Text to speech turns text into a voice reading it aloud. A screen reader processes the content, converts it to speech and to braille, and adds the shortcut keys, the reading modes and the structural navigation on top of that. Used on its own, in a browser read-aloud feature or a reading app, it speaks the text that application decides to hand it, which is normally the visible text rather than the structure around it. So it asks less of your markup than a screen reader does. What it always needs is text from somewhere. A picture of words gives it nothing until something else has pulled the words out first.
In practice
A screen reader has a speech engine inside it, and speech engines get used on their own as well. A browser read-aloud feature, the read-aloud setting on a phone, a reading app used by somebody with dyslexia or low literacy. Products differ in which engines they ship and which they let you swap in, so do not assume two of them sound alike. What is missing when an engine works alone is everything around it, which is the navigation, the roles, the states and the braille.
Braille is the fact that makes the difference impossible to argue with. A screen reader converts content to speech and to braille. A speech engine only speaks. So a read-aloud button on your site offers nothing to a deafblind reader with no usable hearing, where a screen reader driving a braille display does, whatever else the two have in common. There is a third term in W3C's own list, the voice browser, which sits between them and reads web content without being built as an assistive tool.
It also has a place in the standard, in two rules people rarely connect to it. Text-to-speech users are a named beneficiary of the rule requiring a control's accessible name to contain its visible label, because the words they hear should match the words on screen. And W3C frames readable, understandable content as mattering specifically when it is read aloud by text to speech, which is where writing quality stops being a matter of style.
Why it matters
The claim to watch for is that adding a read-aloud button makes a site accessible. It does not, and the reason is structural rather than a matter of opinion. Reading the visible text aloud is not the same job as reporting what everything is, what state it is in, and how to reach it. The second thing worth stating carefully is dyslexia. Text to speech is a recognised accommodation, and W3C describes the useful form of it as hearing and seeing the text together. The research on whether it improves comprehension and fluency is genuinely mixed, so it is an accommodation to offer rather than a result to promise.
The rule written for the voice
WCAG has one criterion aimed squarely at this. 3.1.6 Pronunciation, at Level AAA, asks that where the meaning of a word is ambiguous without knowing how it is said, the pronunciation is available. It is a rule about what a synthesized voice is going to do with your words.
Where this shows up on the site
Related terms
- Screen readerA screen reader is software that reads the screen out loud, or sends it to a braille display, for people who cannot see it.
- Assistive technologyAssistive technology is hardware or software that gives a person with a disability more than a mainstream browser offers on its own.
- DyslexiaDyslexia is a set of processing difficulties that affect the acquisition of reading and spelling.
- Alt textAlt text is the written description attached to an image, and it is what a screen reader reads out in place of the picture.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.