Thoughts on Web Speech API
Last week I spent time working with the Web Speech API for a hackathon at Khan Academy. Here are some quick lessons learned from my experience:
Web Speech is a weird partnership between browser and OS. There are similarities across browsers on a single operating system, and across operating systems with a single browser. Make sure to test as many browser/OS combinations as you can.
Voice has a big impact on how text is read. I was experimenting a lot with
math expressions, and I found some voices would read with correct math
terminology while others would not. For example, on macOS the default voice
(Samantha) reads 3x × 5 as “three times ex five” while Gordon reads it as
“three ex times five”.
The default voice on Ubuntu was really bad. Most of the voices on ChromeOS, macOS, and Windows were fine, but Ubuntu was almost unintelligible. I didn’t play around with other voice options, but it might be a showstopper if you have a significant number of Linux users.
Sometimes speechSynthesis.getVoices() returns an empty array. I couldn’t
find any official documentation about this, but some articles online suggest
that the browser populates that list well after the initial page load. If you
are trying to populate a select field with voice options, make the request for
voices as late as possible.
speechSynthesis.speak() and speechSynthesis.cancel are unpredictably
asynchronous. I think this goes back to the weird partnership between browser
and OS, but calling speak() doesn’t happen immediately and cancel() can
“swallow” subsequent speak() calls. I needed to use timeouts with a 100ms
delay in a few areas to ensure that the utterance would speak when expected.
The Web Speech API is neat, but it has a lot of rough edges. It’s unlikely that a major user-facing feature would use it alone, especially with the rapid developments in AI text-to-speech. That said, Web Speech provides a solid foundation to progressively enhance with more power TTS solutions.