11

Let's say I have the following sentence in HTML:

<p>Please enter your licence number</p>

The screen-reader mis-pronounces the word 'licence' as "liss-ens" (phonetic spelling). It should be pronounced "lice-ens" (phonetic spelling).

I want to fix this by providing a phonetic spelling to the screen-reader, while having the text visually appear the same.

I could use <span>s, aria- attributes and styling as follows:

<p>Please enter your <span aria-hidden="true">licence</span><span style="position: absolute; left: -10000em;">license</span> number</p>

This works well enough, except that the screen-reader (I'm testing with VoiceOver on MacOS) pauses when it gets to the first span, forcing me to press [VO]+[Right Arrow] to advance to the next word:

"Please enter your" ... [VO]+[Right Arrow] ... "lice-ens" ... [VO]+[Right Arrow] ... "number"

I want the screen-reader to read out the sentence smoothly without pausing.

Is this possible? Or should I not be trying to control this?

Jonathan
  • 32,202
  • 38
  • 137
  • 208
  • 3
    fwiw: The simple `

    ... licence ...

    ` is pronounced phonetically correct using VoiceOver on OSX, iOS, and TalkBack on Android in my environments (set to UK English). Personally I wouldn't correct/hack pronunciation. What you _think_ you've fixed for one environment is likely to be wrong in another, unless you have the luxury to test it across all platforms using differing AT Tools, and language settings. If a sight impaired user doesn't understand the spoken word then AT Devices/ Screen Readers typically provide tools to spell the word character by character which helps to disambiguate.     – RobC Apr 19 '17 at 11:06

3 Answers3

32

Don't.

Really, don't worry about it. I know that sounds trite but it is real advice based on years of working with screen reader users (and trying to do what you are trying to do).

Most screen reader users are already familiar with how words are spoken by their tools, the quirks associated with abbreviations, dates, times, etc. By trying to override it you run the risk of confusing your users.

If you speak to a screen reader user you will likely find that this is true. It is so common an issue that it came up yet again on this week's WebAIM mailing list: http://webaim.org/discussion/mail_message?id=34398

Note this insightful comment from the thread:

In fact, sometimes if you listen very carefully to a screen reader user talking, you can catch that we will pronounce words the same as our screen readers do--and we are not even aware of it.

Definitely do not try to repurpose <ruby>. In general, if you do not understand an element then do not use it, and certainly not as a hack. That can cause problems for people trying to auto-translate the content.

Also, do not use a hack if you are not prepared to test it across all screen reader and platform combinations (including multiple versions of each screen reader and browser pairing).

Finally, remember that about 1/3 of screen reader users have vision, so sometimes forced pronunciation will mess with what they are seeing on screen.

Community
  • 1
  • 1
aardrian
  • 8,581
  • 30
  • 40
  • 4
    A well-reasoned "don't" is always the best accessibility advice. – Justin Apr 19 '17 at 16:21
  • Love the "don't" answer! It's often my go to answer for accessibility related questions. Would suggest throwing in a potential solid "hack" implementation. It keeps developers who don't accept your reasoning from creating duplicate questions! Had that happen to me on many accessibility related questions I had answered simply citing WCAG and saying "don't do this!". Unfortunately, the "copy and paste" code answers inevitably become more popular, because they're easier for developers then telling their manager the requirement that lead them to seek such solutions was misguided. – MobA11y Apr 20 '17 at 17:27
  • 1
    Agreed on the code point, and in many answers I include a least-offensive hack, but I opted not to with this one. I hear so many users passionately describe this issue that I felt like I'd be a jerk if I offered a way around it. – aardrian Apr 20 '17 at 19:26
  • Unfortunately, *not* doing it can be just as bad or worse. I'm trying to make a diplomatic edition of a 15th century book accessible, but a word like `ñl` needs to be pronounced `en el` rather than `ene ele`, and `dõde eſtã` as `dónde están` not `dode eta` . Given that such abbreviations are in virtually every word, the default reading is, frankly, unintelligible. W3C is working on it, but it probably won't be a viable solution for a while: https://www.w3.org/TR/pronunciation-use-cases/ – user0721090601 Feb 09 '20 at 20:02
  • Ongoing confirmation from Léonie Watson, SR user: https://lists.w3.org/Archives/Public/w3c-wai-ig/2020OctDec/0047.html – aardrian Nov 12 '20 at 17:28
1

I think I found a solution. This seems to work with VoiceOver on MacOS. (Haven't tested it with other screen-readers such as JAWS.)

The solution is to repurpose the <ruby> element, using CSS to override its styling:

Please enter your 
<ruby>
  <rt aria-hidden="true" style="font-size: 1em"><!--Standard-->licence</rt>
  <rt style="display: inline-block; width: 1px; height: 1px; overflow: hidden"><!--Phonetic-->license</rt>
</ruby>
 number

This displays the correct string and also reads it out with the phonetic pronunciation without pausing.

But I'm open to other/better solutions. Or critique of the question itself. :)

unor
  • 92,415
  • 26
  • 211
  • 360
Jonathan
  • 32,202
  • 38
  • 137
  • 208
0

This works, sort of:

<span aria-label="license">licence</span>

If the span element is the AT's focus, it would be announced as having a role of "group", which can be overridden with an aria-roledescription attribute (only non-whitespace values allowed). The role is not described when reading sentences or paragraphs.

Nicholas Shanks
  • 10,623
  • 4
  • 56
  • 80
  • 1
    https://developer.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/ – aardrian Feb 21 '20 at 15:07