Someone recently raised the interesting point that they found the Narrator screen reader pronounces “3 + 1” as “three plus one” when interacting with their app, yet it pronounces “3 – 1” as “three to one”. They were curious as to whether they could tell Narrator to pronounce the ‘-’ as “minus”.
Today there is no way for the app developer to force Narrator to use some particular pronunciation for the text exposed by the app UI. If your app exposes the text as “3 – 1”, then Narrator will simply pass that text to the Text-To-Speech (TTS) engine being used by Narrator, and your customer will hear the text with whatever pronunciation the TTS engine wants to use.
So when the TTS engine encounters the ‘-’, maybe it’ll say “to”, “minus”, “dash” or nothing at all. And the TTS engine could say something quite different if the character is actually a ‘–’ instead of a ‘-’.
But depending on your situation, maybe there are a couple of things you could consider when pondering options for your own customers. I’ve described those options below. You may well feel that for your app, it’s appropriate to not take any special action, and go with the default Narrator experience.
Achieve the desired pronunciation by setting the accessible name on the element in your UI
If say you have a XAML element displaying the text “3 – 1”, it would often be quite straightforward to set an accessible name on the element of “3 minus 1”. Narrator would access that accessible name, and pass that text to the TTS engine, which would speak it exactly as supplied. (Of course, “minus” would need to be localized in all the languages that your app ships.)
In some cases this might be your best option, given that you have absolute control over what’s going to be spoken. And in fact when a button simply shows a symbolic text character, for example ‘?’, we’d always set an accessible name on that button in order to provide a helpful, consistent experience regardless of what TTS engine is currently being used.
But if a ‘-’ is part of some large text content being presented in your app, (say like the document content I’m writing here,) then you’re not going to be setting an explicit accessible name on all that content just to control how the ‘-’ is pronounced.
To learn more about setting accessible names on elements in your UI, see Giving your XAML element an accessible name.
Take advantage of common TTS behavior
If the TTS engine isn’t given instructions on how to pronounce some text, it’ll take its best guess. And how one TTS engine pronounces the text might be different to how another TTS engine pronounces the same text.
But there are some behaviors that are fairly common across TTS engines. For example, if a ‘-’ is preceded by a space, and followed immediately by a number then a space, the TTS engine will often pronounce the ‘-’ as “minus”. So if I type “3 -1 ” in Word 2013 here, and have Narrator speak that text, I hear “3 minus 1”.
So perhaps in some cases, this simple change could get the desired results for your customers who use Narrator. It does have the drawback that the visual text is also changing, and that might be unacceptable.
An example of how different TTS engines say different things
In some situations you might opt for using spaces or punctuation in your text to take advantage of common behaviors across TTS engines regarding pronunciation. But taking the approach of changing the text exposed by your UI because it triggers some response by the TTS engine that you happen to be using, can lead to unpredictable results for your customers who use different TTS engines. For example, while both the Microsoft David (US) and Microsoft Hazel (UK) TTS engines pronounce “mph” as “miles per hour”, David pronounces “st.” as “s t”, and Hazel pronounces it as ”street”.
And Hazel happily pronounces “HRH” as “his royal highness”. To get David to say that, you’d have to set the accessible name on the element containing the text. A straightforward way of setting such an accessible name would be as follows:
<TextBlock x:Uid=”TTSDemoTextBlock” />
Localized string resource file:
<data name=”TTSDemoTextBlock.Text” xml:space=”preserve”>
<comment>Demo string shown visually in the app on a TextBlock</comment>
<data name=”TTSDemoTextBlock.[using:Windows.UI.Xaml.Automation]AutomationProperties.Name” xml:space=”preserve”>
<value>His Royal Highness Bob</value>
<comment>Localized accessible name for the demo TextBlock</comment>
Now I hear Narrator say “His Royal Highness Bob” when reaching the TextBlock regardless of what TTS engine I’m using.
Figure 1: Narrator highlighting a TextBlock visually presenting the text “HRH Bob”.