More Precise Text-to-Speech in Your Website:
A HowtoMore Precise Text-to-Speech in Your Website: A Howto

Problem

How to pronounce a word is not always obvious unless you have its context and a rule. But, even in uncertain cases, once you know how you want it said in a certain context, you can provide that rule without altering what sightful visitors see. You can write whatever you like for all users and provide accurate rendering both for sightful and for blind and visually impaired visitors.

Text-to-speech (TTS) programs convert visual text on a screen the visitors cannot see into audible speech they can hear. But English and likely most popular natural languages have many common words that have multiple pronunciations each. TTS programs are probably not smart enough to understand from a context how a word should be pronounced.

Bad ideas include letting TTS do whatever it does or modifying what can be seen with normal sight. But leaving TTS to make its own mistakes can lead to severe misunderstandings, especially for short text, such as when past and present tenses get mixed up without alerting the listener. SSML is another bad idea, in my opinion, because writing it (Speech Synthesis Markup Language) requires a parallel set of pages, bad enough for a site that doesn’t change but worse if you do even minor maintenance from time to time, and you’ll need to maintain expertise in SSML or refresh yourself at times. I have enough work to do. I don’t do SSML parallel pages. And, “[b]y the way, SSML isn’t supported in any browsers yet” (Frequent11y (Month11y issue 34 (Dec. 16, 2022)), section Why We Need CSS Speech).

Solution

Instead, where there’s ambiguity, I go off-page and supply the preferred pronunciation for the whole context. It’s work and I miss most strings that need it, but the workload is a separate issue. Fortunately, at least I have a method that provides a support structure.

I apply the Pronunciation Lexicon Specification (PLS). Using it, I create a *.pls file, which I like to name pronunciation.pls and which I place in the root level of a website of mine. The pronunciation.pls file gives pronunciation rules that are particular to that website. Keep in mind that the context has to be unique not only for the page but for the whole website and there’s probably no system for limiting an entry in the *.pls file to a particular page (at least where one *.pls file is placed loose to serve a whole website), so what you should do is copy more of the context so that the context will be unique across the whole website.

I write the file in a text editor.

You can make it more readable by adding blank lines and comments.

You can see the one for this site at <http://BrittleBit.org/pronunciation.pls>.

Then I link the *.html files with the *.pls file, and I do that in every *.html file, where, in the head element, I add this link element:

Each website can have its own rules, which makes sense since usually each website has unique text even for sightful readers.

One difficulty is that I edit text fairly often and may forget that an old string is also in the *.pls file and that the *.pls file also needs editing. If I edit the HTML file but forgot to conform the *.pls file, the result will be a failure to match and my *.pls instruction will be ignored by the user’s software. I suppose I could surround it in the HTML page with a span element or a comment that would do nothing to the rendering but would remind me that an edit to that string would require a *.pls review.

Complex Sites

For large websites or where you control only part of a website, or where a *.pls file is getting too unwieldy, a probable solution may be to do this system for each directory. The HTML link would link to the *.pls file in a specific directory and the *.pls file would be placed in accordance with that link. That should work; but I haven’t tested it. Since a website is often hosted (served to the public) from a server where many sites share space and each site has its own directories (folders), using PLS on a per-directory basis would almost certainly succeed and might make your work easier.

Bottom Line

Even with the site-wide system, now I have a place to add site-specific rules wherever I need clarity.