E-mail List Archives
Thread: Forcing screen reader pronunciation of abbreviation important to a brand
Number of posts in this thread: 24 (In chronological order)
From: JR Accessibility
Date: Fri, Apr 13 2018 7:54AM
Subject: Forcing screen reader pronunciation of abbreviation important to a brand
No previous message | Next message →
Is it possible to force a screen reader to pronounce a two-letter
abbreviation a certain way, rather than the way the screen reader software
wants to pronounce it?
In a previous WebAIM discussion from 2014, Geri Druckman suggested using
the HTML <abbr> tag, but I cannot get that to work.
https://webaim.org/discussion/mail_thread?threadb65
For the sake of example suppose my company's name is Nova-Echo but we go by
NE (which should be pronounced 'N E') in our product numbers and in our
preferred customer program, MyNE (which should be pronounced 'My N E').
The default pronunciation of the letters 'N' and 'E' next to each other in
NVDA is 'northeast' and in JAWS it is 'knee'. This leads to undesirable
pronunciations of our product numbers, such as 'northeast 1234' or 'knee
1234', and of our preferred customer program 'my northeast' or 'my knee'.
How can we force the screen readers to pronounce these items the way we
want them to?
I have placed some sample HTML on my Google Drive, that contains additional
examples:
https://drive.google.com/file/d/1SiAN6ewa70q9L_SqmcxIwIuYQv_mEKRr/view?usp=sharing
Also a spreadsheet with the pronunciations I observed in NVDA and JAWS:
https://drive.google.com/open?idC3RhocHOdtuGJ0uopLfQtGA4EF3pWEusM_ANYQB9Kc
Thank you very much.
From: JP Jamous
Date: Fri, Apr 13 2018 9:53AM
Subject: Re: Forcing screen reader pronunciation of abbreviationimportant to a brand
← Previous message | Next message →
You can accomplish this by various ways. It depends on the situation you have at hand. The bottom line is you use ARIA to hijack the HTML element. It may not be the best method from a semantic prospective, but it gets the job done.
For example if I have a paragraph:
<p>
You have purchased NE1254 for $300.
</p>
You can hijack NE1254 using ARIA.
<p>
You have purchased
<span aria-label=" N E 1254">
NE1254</span>
for $300.
</p>
I hope that helps.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: Jonathan Avila
Date: Fri, Apr 13 2018 10:22AM
Subject: Re: Forcing screen reader pronunciation ofabbreviationimportant to a brand
← Previous message | Next message →
I would be careful about assuming that screen readers will announce aria-label on non-interactive elements. Also when you write out phonetically things it has a negative impact on braille. I blogged about this a few years ago.
https://www.levelaccess.com/zip-z-p-z-p-forcing-correct-pronunciation-screen-readers/
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: Duff Johnson
Date: Fri, Apr 13 2018 10:29AM
Subject: Re: Forcing screen reader pronunciation ofabbreviation important to a brand
← Previous message | Next message →
I thought you all were W3C people! ;-)
This was incorporated into PDF 2.0, which was published last year.
Pronunciation Lexicon Specification (PLS) Version 1.0, (October 2008), https://www.w3.org/TR/pronunciation-lexicon/
How (and whether) browsers understand this stuff for AT purposes is something I don't know...
Duff.
> On Apr 13, 2018, at 12:22, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
> I would be careful about assuming that screen readers will announce aria-label on non-interactive elements. Also when you write out phonetically things it has a negative impact on braille. I blogged about this a few years ago.
> https://www.levelaccess.com/zip-z-p-z-p-forcing-correct-pronunciation-screen-readers/
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
>
>
From: glen walker
Date: Fri, Apr 13 2018 10:39AM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
You may have limited success specifying an aria-label for a <span>
element. A span doesn't have a role so its accessible name is not normally
computed so the aria-label is often ignored.
Also, when you split up your sentence with a <span>, that causes a "tab
stop" for VoiceOver (at least on iOS). When you swipe right through the
sentence, it'll stop when it hits the <span>. You then have to swipe again
to read the span, then swipe again to read the rest of the sentence.
You can try adding a role="text" to the <p>. That might be considered a
"hack" but it solves both problems on iOS. It reads the aria-label and it
treats the entire sentence as one block instead of splitting it up.
<p role="text">
You have purchased <span aria-label=" N E 1254"> NE1254</span> for $300.
</p>
You'd have to play with JAWS and NVDA to see how well it works there. When
I tried your original example, NE was pronounced as N E instead of
northeast or knee, so I couldn't tell if my solution worked.
On Fri, Apr 13, 2018 at 9:53 AM, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> You can accomplish this by various ways. It depends on the situation you
> have at hand. The bottom line is you use ARIA to hijack the HTML element.
> It may not be the best method from a semantic prospective, but it gets the
> job done.
>
> For example if I have a paragraph:
>
> <p>
> You have purchased NE1254 for $300.
> </p>
> You can hijack NE1254 using ARIA.
>
> <p>
> You have purchased
> <span aria-label=" N E 1254">
> NE1254</span>
> for $300.
> </p>
>
> I hope that helps.
>
> --------------------
> JP Jamous
> Senior Digital Accessibility Engineer
> E-Mail Me |Join My LinkedIn Network
> --------------------
>
>
>
From: Jonathan Avila
Date: Fri, Apr 13 2018 10:50AM
Subject: Re: Forcing screen reader pronunciation ofabbreviation important to a brand
← Previous message | Next message →
> How (and whether) browsers understand this stuff for AT purposes is something I don't know...
I haven't' looked at a demo page but I don't think this information is communicated through the accessibility API to screen readers and thus not passed to TTS engines. Internally in JAWS scripts there is some support to control the TTS using markup -- but as far as I know that is not controllable by content authors. So in practical reality if there is no accessibility support for something created 10 years ago I don't see it as a viable option. It might be helpful to know what user agents this specification has been implemented in such as voice assistants, etc.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: JP Jamous
Date: Fri, Apr 13 2018 11:39AM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
Thanks for clarifying it. I actually did not test it before sending it out, as I was in the middle of something. I wrote it out of memory to help point him in the right direction.
Thank you for the extra knowledge.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: Duff Johnson
Date: Fri, Apr 13 2018 12:00PM
Subject: Re: Forcing screen reader pronunciation ofabbreviation important to a brand
← Previous message | Next message →
> I haven't' looked at a demo page but I don't think this information is communicated through the accessibility API to screen readers and thus not passed to TTS engines.
That's interesting. To get that far the spec is (I believe?) supposed to have at least a couple of implementations…?
> Internally in JAWS scripts there is some support to control the TTS using markup -- but as far as I know that is not controllable by content authors. So in practical reality if there is no accessibility support for something created 10 years ago I don't see it as a viable option.
Well… if JAWS doesn't do it that's mostly a statement about JAWS… and the actual size of this marketplace, not (necessarily) the quality or utility of the spec… :-(
> It might be helpful to know what user agents this specification has been implemented in such as voice assistants, etc.
It would indeed!
Duff.
From: Tim Harshbarger
Date: Fri, Apr 13 2018 12:20PM
Subject: Re: [EXTERNAL]Forcing screen reader pronunciation of abbreviationimportant to a brand
← Previous message | Next message →
Personally, I would recommend not altering how the screen reader pronounces the acronym--unless you have specific evidence that demonstrates that it is causing problems for your users.
Those of us who rely on screen readers are actually quite familiar with how screen readers pronounce or mispronounce words. In fact, the only time I think I know of where such a thing created more than just a minor nuisance was when the actual word and the mispronounced word both fit the context. For example, NE. In the context of directions having NVDA read NE as northeast when it could mean either the direction or an acronym for a company would be confusing. NVDA saying "northeast" for NE in a context where it would only refer to the company's acronym would not.
Again I wouldn't spend time trying to do this unless you have specific information indicating that it is causing problems for screen reader users.
Thanks,
Tim
From: Birkir R. Gunnarsson
Date: Sun, Apr 15 2018 11:41AM
Subject: Re: [EXTERNAL]Forcing screen reader pronunciation of abbreviationimportant to a brand
← Previous message | Next message →
USAA has a table of commonly used abbreviations and instructions on
how to add them to Jaws and NVDA dictionaries:
https://www.usaa.com/inet/pages/accessibility_at_usaa_main?akredirect=true
(you have to expand the desktop help section to see the tables).
This is a somewhat leftfield approach, but I find it interesting for
issues where screen reader pronounciation of words or abbreviations
cannot be explicitly forced by the author.
You can even put a sentence about adding common acronyms to
dictionaries on the homepage of your site, you can visually hide it.
Granted, I don't know if Voiceover offers custom pronounciation
dictionaries, I've never come across one.
Of course the real solution is for the author to code to spec and user
agents implementing that spec correctly.
I have had quite a few rants on here about how I think holding web
developers responsible for working around user agent shortcomings
implementing published standards is making accessibility difficult,
costly, and unreliable, but I'll let it go for now *grin*.
On 4/13/18, Tim Harshbarger < = EMAIL ADDRESS REMOVED = > wrote:
> Personally, I would recommend not altering how the screen reader pronounces
> the acronym--unless you have specific evidence that demonstrates that it is
> causing problems for your users.
>
> Those of us who rely on screen readers are actually quite familiar with how
> screen readers pronounce or mispronounce words. In fact, the only time I
> think I know of where such a thing created more than just a minor nuisance
> was when the actual word and the mispronounced word both fit the context.
> For example, NE. In the context of directions having NVDA read NE as
> northeast when it could mean either the direction or an acronym for a
> company would be confusing. NVDA saying "northeast" for NE in a context
> where it would only refer to the company's acronym would not.
>
> Again I wouldn't spend time trying to do this unless you have specific
> information indicating that it is causing problems for screen reader users.
>
> Thanks,
> Tim
>
>
From: Jonathan Cohn
Date: Sun, Apr 15 2018 12:46PM
Subject: Re: [EXTERNAL]Forcing screen reader pronunciation of abbreviationimportant to a brand
← Previous message | Next message →
For Macintosh VoiceOver:
1. Open VoiceOver Utility with Control-option-F8
2. Switch to Speech panel command-three
3. Switch to pronunciation tab.
There you find a table with four columns:
Original, Prononciation, Case Sensitive, Application.
I understand that IOS 11 also has a voiceover pronunciation dictionary but I have never reviewed that.
Best wishes,
Jonathan Cohn
> On Apr 15, 2018, at 1:41 PM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> USAA has a table of commonly used abbreviations and instructions on
> how to add them to Jaws and NVDA dictionaries:
> https://www.usaa.com/inet/pages/accessibility_at_usaa_main?akredirect=true
> (you have to expand the desktop help section to see the tables).
> This is a somewhat leftfield approach, but I find it interesting for
> issues where screen reader pronounciation of words or abbreviations
> cannot be explicitly forced by the author.
> You can even put a sentence about adding common acronyms to
> dictionaries on the homepage of your site, you can visually hide it.
> Granted, I don't know if Voiceover offers custom pronounciation
> dictionaries, I've never come across one.
> Of course the real solution is for the author to code to spec and user
> agents implementing that spec correctly.
> I have had quite a few rants on here about how I think holding web
> developers responsible for working around user agent shortcomings
> implementing published standards is making accessibility difficult,
> costly, and unreliable, but I'll let it go for now *grin*.
>
>
>
> On 4/13/18, Tim Harshbarger < = EMAIL ADDRESS REMOVED = > wrote:
>> Personally, I would recommend not altering how the screen reader pronounces
>> the acronym--unless you have specific evidence that demonstrates that it is
>> causing problems for your users.
>>
>> Those of us who rely on screen readers are actually quite familiar with how
>> screen readers pronounce or mispronounce words. In fact, the only time I
>> think I know of where such a thing created more than just a minor nuisance
>> was when the actual word and the mispronounced word both fit the context.
>> For example, NE. In the context of directions having NVDA read NE as
>> northeast when it could mean either the direction or an acronym for a
>> company would be confusing. NVDA saying "northeast" for NE in a context
>> where it would only refer to the company's acronym would not.
>>
>> Again I wouldn't spend time trying to do this unless you have specific
>> information indicating that it is causing problems for screen reader users.
>>
>> Thanks,
>> Tim
>>
>>
From: Tim Harshbarger
Date: Mon, Apr 16 2018 6:42AM
Subject: Re: [EXTERNAL]Forcing screen reader pronunciation of abbreviationimportant to a brand
← Previous message | Next message →
It is also possible to change the pronunciation of words in iOS also. You need to go to the VO settings and tap the Speech button. There is a "pronunciation" button that takes you to a screen where you can change the pronunciation of words. There might be a quicker way to get there though.
From: Birkir R. Gunnarsson
Date: Mon, Apr 16 2018 9:21AM
Subject: Re: [EXTERNAL]Forcing screen reader pronunciation of abbreviationimportant to a brand
← Previous message | Next message →
One more thing to be mindful of.
Some screen readers (Jaws at least) give you the ability to define a
very specific context for the pronunciation, e.g. a webpate or
website.
If it is not possible to define context, keep in mind the user is
changing the way these letters are pronounced in every usage context,
on the web and in other applications, which is not necessarily a good
idea.
I need to study the pronounciation dsettings of NVDA and Voiceover to
see what context can be defined.
On 4/16/18, Tim Harshbarger < = EMAIL ADDRESS REMOVED = > wrote:
> It is also possible to change the pronunciation of words in iOS also. You
> need to go to the VO settings and tap the Speech button. There is a
> "pronunciation" button that takes you to a screen where you can change the
> pronunciation of words. There might be a quicker way to get there though.
> > > > >
--
Work hard. Have fun. Make history.
From: Karlen Communications
Date: Mon, Apr 16 2018 10:21AM
Subject: Re: [EXTERNAL]Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
Also keep in mind that pronunciation depends on the synthesized voice used for the screen reader or Text-to-Speech tool. While Eloquence will pronounce "wasted" as wasted" UK Daniel pronounces it as "was ted." Same screen reader, different synthesized voice.
Cheers, Karen
From: JR Accessibility
Date: Mon, Apr 16 2018 12:32PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
(Sorry this isn't a reply to the long email chain I started... I couldn't
figure out how to do that from the digest mode messages.)
Continuing the topic of "Forcing screen reader pronunciation of
abbreviation important to a brand."
I partially agree with the sentiment that this is only a problem if real
users are having a problem, but it's also a significant concern to certain
brands.
For example, take the the abbreviation NW or 'northwest' as some screen
readers will insist on pronouncing it. In the case of a preferred customer
program called MyNW, some screen readers will insist this is 'my
northwest'. If you are in the banking industry, this could get mixed up
with Northwest Bank (and yes, that's a real bank).
Another example: SW or 'southwest' depending on screen reader. 'MySW' is
going to be pronounced 'my southwest' by some screen readers. Does this
refer to a customer program for the major airline company that owns the URL
www.southwest.com ? That seems really confusing, particularly if the
customer belong to the Southwest Airlines program and is also shopping some
other site with the initials SW.
For the record, I cannot get any of the proposed solutions involving spans
and aria-labels to work with out-of-the-box JAWS and NVDA. My JAWS and NVDA
continue to insist upon pronouncing NW, SW, SE, and NE in their own ways
regardless of what markup I put around those letters.
From: glen walker
Date: Mon, Apr 16 2018 12:59PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
> For the record, I cannot get any of the proposed solutions involving
spans and aria-labels to work with out-of-the-box JAWS and NVDA.
Because your text is not an interactive object. It's just plain text. I
hesitate to mention this because it's a total hack and a terrible UI, but
if you made the words a link, then you could specify an aria-label. The
link wouldn't go anywhere (current page) but at least you'd have the
correct pronunciation.
<a href='javascript:void(0)' aria-label='my N E'>MyNE</a>
On Mon, Apr 16, 2018 at 12:32 PM, JR Accessibility <
= EMAIL ADDRESS REMOVED = > wrote:
> (Sorry this isn't a reply to the long email chain I started... I couldn't
> figure out how to do that from the digest mode messages.)
>
> Continuing the topic of "Forcing screen reader pronunciation of
> abbreviation important to a brand."
>
> I partially agree with the sentiment that this is only a problem if real
> users are having a problem, but it's also a significant concern to certain
> brands.
>
> For example, take the the abbreviation NW or 'northwest' as some screen
> readers will insist on pronouncing it. In the case of a preferred customer
> program called MyNW, some screen readers will insist this is 'my
> northwest'. If you are in the banking industry, this could get mixed up
> with Northwest Bank (and yes, that's a real bank).
>
> Another example: SW or 'southwest' depending on screen reader. 'MySW' is
> going to be pronounced 'my southwest' by some screen readers. Does this
> refer to a customer program for the major airline company that owns the URL
> www.southwest.com ? That seems really confusing, particularly if the
> customer belong to the Southwest Airlines program and is also shopping some
> other site with the initials SW.
>
> For the record, I cannot get any of the proposed solutions involving spans
> and aria-labels to work with out-of-the-box JAWS and NVDA. My JAWS and NVDA
> continue to insist upon pronouncing NW, SW, SE, and NE in their own ways
> regardless of what markup I put around those letters.
> > > > >
From: Jonathan Cohn
Date: Mon, Apr 16 2018 1:57PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
I seem to remember some voice CSS code that was supposed to force reading by character or some equivalent. I never really tested it, and my memory is that only VoiceOver supported the library.
I am at a point where I could test with NVDA/JAWS/VoiceOver right now if somebody can find this in a CodePan.
Jonathan
> On Apr 16, 2018, at 2:32 PM, JR Accessibility < = EMAIL ADDRESS REMOVED = > wrote:
>
> (Sorry this isn't a reply to the long email chain I started... I couldn't
> figure out how to do that from the digest mode messages.)
>
> Continuing the topic of "Forcing screen reader pronunciation of
> abbreviation important to a brand."
>
> I partially agree with the sentiment that this is only a problem if real
> users are having a problem, but it's also a significant concern to certain
> brands.
>
> For example, take the the abbreviation NW or 'northwest' as some screen
> readers will insist on pronouncing it. In the case of a preferred customer
> program called MyNW, some screen readers will insist this is 'my
> northwest'. If you are in the banking industry, this could get mixed up
> with Northwest Bank (and yes, that's a real bank).
>
> Another example: SW or 'southwest' depending on screen reader. 'MySW' is
> going to be pronounced 'my southwest' by some screen readers. Does this
> refer to a customer program for the major airline company that owns the URL
> www.southwest.com ? That seems really confusing, particularly if the
> customer belong to the Southwest Airlines program and is also shopping some
> other site with the initials SW.
>
> For the record, I cannot get any of the proposed solutions involving spans
> and aria-labels to work with out-of-the-box JAWS and NVDA. My JAWS and NVDA
> continue to insist upon pronouncing NW, SW, SE, and NE in their own ways
> regardless of what markup I put around those letters.
> > > >
From: Mohith BP
Date: Mon, Apr 16 2018 11:32PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
Hi,
The solution for your issue is:
1. Hide the visible text from the screen readers by providing a span
around the text with the aria-hidden="true"
2. Provide visually hidden text in the same place.
Please refer the following article and there are couple of ways to
hide the text visually through CSS.
https://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content
Thanks & Regards,
Mohith B. P.
On 4/13/18, JR Accessibility < = EMAIL ADDRESS REMOVED = > wrote:
> Is it possible to force a screen reader to pronounce a two-letter
> abbreviation a certain way, rather than the way the screen reader software
> wants to pronounce it?
>
> In a previous WebAIM discussion from 2014, Geri Druckman suggested using
> the HTML <abbr> tag, but I cannot get that to work.
> https://webaim.org/discussion/mail_thread?threadb65
>
>
> For the sake of example suppose my company's name is Nova-Echo but we go by
> NE (which should be pronounced 'N E') in our product numbers and in our
> preferred customer program, MyNE (which should be pronounced 'My N E').
>
> The default pronunciation of the letters 'N' and 'E' next to each other in
> NVDA is 'northeast' and in JAWS it is 'knee'. This leads to undesirable
> pronunciations of our product numbers, such as 'northeast 1234' or 'knee
> 1234', and of our preferred customer program 'my northeast' or 'my knee'.
>
> How can we force the screen readers to pronounce these items the way we
> want them to?
>
>
> I have placed some sample HTML on my Google Drive, that contains additional
> examples:
> https://drive.google.com/file/d/1SiAN6ewa70q9L_SqmcxIwIuYQv_mEKRr/view?usp=sharing
>
> Also a spreadsheet with the pronunciations I observed in NVDA and JAWS:
> https://drive.google.com/open?idC3RhocHOdtuGJ0uopLfQtGA4EF3pWEusM_ANYQB9Kc
>
> Thank you very much.
> > > > >
From: Mallory
Date: Tue, Apr 17 2018 3:34PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
I find it personally disingenuous that screen reader software substitutes almost random words for letters. Sighted people aren't given this-- they see CO and use the context to mentally call that "country", "colorado", "company" or something else. Imagine if browsers changed those visually to the other words-- users would be up in arms and not everyone can or will always realise they're hearing some SR BS rather than the actual content.
It's kinda like translators taking "rays of light" coming out of Moses' head and translating it to "horns" and then you get weird-looking statues.
I get the danger of web devs doing a bunch of hacks to force any pronunciation, and tend to recommend they don't do it, but giving people clearly-wrong data can't ever be good.
cheers,
_mallory
On Tue, Apr 17, 2018, at 7:32 AM, Mohith BP wrote:
> Hi,
>
> The solution for your issue is:
> 1. Hide the visible text from the screen readers by providing a span
> around the text with the aria-hidden="true"
> 2. Provide visually hidden text in the same place.
>
> Please refer the following article and there are couple of ways to
> hide the text visually through CSS.
> https://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content
>
>
> Thanks & Regards,
> Mohith B. P.
> On 4/13/18, JR Accessibility < = EMAIL ADDRESS REMOVED = > wrote:
> > Is it possible to force a screen reader to pronounce a two-letter
> > abbreviation a certain way, rather than the way the screen reader software
> > wants to pronounce it?
> >
> > In a previous WebAIM discussion from 2014, Geri Druckman suggested using
> > the HTML <abbr> tag, but I cannot get that to work.
> > https://webaim.org/discussion/mail_thread?threadb65
> >
> >
> > For the sake of example suppose my company's name is Nova-Echo but we go by
> > NE (which should be pronounced 'N E') in our product numbers and in our
> > preferred customer program, MyNE (which should be pronounced 'My N E').
> >
> > The default pronunciation of the letters 'N' and 'E' next to each other in
> > NVDA is 'northeast' and in JAWS it is 'knee'. This leads to undesirable
> > pronunciations of our product numbers, such as 'northeast 1234' or 'knee
> > 1234', and of our preferred customer program 'my northeast' or 'my knee'.
> >
> > How can we force the screen readers to pronounce these items the way we
> > want them to?
> >
> >
> > I have placed some sample HTML on my Google Drive, that contains additional
> > examples:
> > https://drive.google.com/file/d/1SiAN6ewa70q9L_SqmcxIwIuYQv_mEKRr/view?usp=sharing
> >
> > Also a spreadsheet with the pronunciations I observed in NVDA and JAWS:
> > https://drive.google.com/open?idC3RhocHOdtuGJ0uopLfQtGA4EF3pWEusM_ANYQB9Kc
> >
> > Thank you very much.
> > > > > > > > > >
> > > >
From: Andrews, David B (DEED)
Date: Wed, Apr 18 2018 6:41AM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
I think that some os the substitutions come from the text-to-speech engines, so let's be careful with blanket condemnations.
Dave
David Andrews | Chief Technology Officer
Minnesota Department of Employment and Economic Development
State Services for the Blind
2200 University Ave West, Suite 240, St. Paul MN 55114
Direct: 651-539-2294
Web | Twitter | Facebook
From: JR Accessibility
Date: Wed, Apr 18 2018 2:21PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
https://codepen.io/jr-accessibility/pen/zjYeZE
Eureka! Thanks to Mohith BP this is working in NVDA with Firefox. There is
a pause because of the (span) but at least the abbreviation is being
pronounced the way I want it to be.
From: Glen Walker
Date: Wed, Apr 18 2018 2:35PM
Subject: Re: Forcing screen reader pronunciation of abbreviation important to a brand
← Previous message | Next message →
If you made the entire sentence hidden instead of just the abbreviation part, you wouldn't get a pause.
Sent from my iPhone
> On Apr 18, 2018, at 2:21 PM, JR Accessibility < = EMAIL ADDRESS REMOVED = > wrote:
>
> https://codepen.io/jr-accessibility/pen/zjYeZE
>
> Eureka! Thanks to Mohith BP this is working in NVDA with Firefox. There is
> a pause because of the (span) but at least the abbreviation is being
> pronounced the way I want it to be.
> > > >
From: Bryan Garaventa
Date: Fri, Apr 20 2018 11:51AM
Subject: Re: Forcing screen reader pronunciation ofabbreviationimportant to a brand
← Previous message | Next message →
Hi,
As others have already pointed out, I don't recommend this except in some very rare circumstances.
ARIA was mentioned as a fix for this, but the recommended ways of doing this may be problematic across various platforms where support levels differ, so here is one that works more reliably.
The trick here is to use aria-owns to change the accessibility tree without impacting the DOM, like so. This changes "BEG" to "B E G", however it has no impact on the DOM or the styling of the visible text.
<b aria-owns="space1">B</b><b aria-owns="space2">E</b><b>G</b>
Then the following can be appended to the end of the body element so nobody will notice it.
<i><b id="space1"> </b><b id="space2"> </b></i>
This appends a space character at the end of the B and E letters in the accessibility tree, and this is what causes the separation to occur between them.
A few notes about this: Unlike other ARIA attributes like aria-labelledby or aria-describedby which can reference hidden elements, aria-owns doesn't work like this and won't render hidden elements. Also this technique should never be used on elements that don't support children like IMG elements or input elements, because this forces the accessibility tree to change and any content that is referenced like this will disappear and become impossible to navigate and interact with normally. Also using this method should never be used to move focusable interactive elements around because this does not change the tab order. The use of aria-owns cannot reference the same ID from different attributes, so each referenced node has to be different as shown above.
All the best,
Bryan
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
From: KellyFord
Date: Mon, Apr 23 2018 9:27PM
Subject: Re: Forcing screen reader pronunciationofabbreviationimportant to a brand
← Previous message | No next message
Hi,
One thing to keep in mind, any solution that changes the text, such as inserting spaces, runs the risk of causing a poorer reading experience for users who are working with Braille. Those spaces will likely be present in the Braille text.
This could also cause confusion if a speech user wants to know the spelling of the text and starts reading by character. They will then perceive that the word is written with space characters and could mistakenly reproduce that error when they go to write the word themselves, if they want to refer to this same brand for example.
Kelly