E-mail List Archives
Thread: Keyboard accessibility of abbreviations
Number of posts in this thread: 21 (In chronological order)
From: Nasrin.Saef
Date: Thu, Apr 16 2015 4:29AM
Subject: Keyboard accessibility of abbreviations
No previous message | Next message →
Hi List,
I'm currently trying to improve the keyboard accessibility of our website and recently decided to tackle abbreviations. According to the German accessibility regulations (and I'm sure there are equivalent success criteria in the WCAG) all functionality must be accessible by keyboard, and the expanded form of all abbreviations must be accessible to all users.
To achieve this, we set up this javascript solution: https://jsfiddle.net/saenas/un40y5ey/
But while it should fulfill the SC, we're not sure how good it is from a usability viewpoint. Since we provide medical information, there are a lot of abbreviations on our website, and implementing this solution (or any like it, really) forces keyboard users to tab a lot more. Additionally, while it is supposed to only expand the first instance of each abbreviation per page, this mechanism doesn't work for the navigation and the sidebar - so an abbreviation that is present in each element would be expanded three times.
For reference, here is a link to one of our pages that contains LOTS of abbreviations: http://www.dimdi.de/static/de/klassi/index.htm
That's why I'd like to ask keyboard users here: what do you think of such a solution? Do you think it would improve your experience or make it worse? Does anyone have suggestions for improvement?
Thank you for your feedback!
From: Steve Faulkner
Date: Thu, Apr 16 2015 4:45AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
On 16 April 2015 at 11:29, < = EMAIL ADDRESS REMOVED = > wrote:
> Does anyone have suggestions for improvement?
The first time an uncommon abbreviation is used in a page provide the
expansion:
example:
<abbr>W3C</abbr> (World Wide Web Consortium)
subsequent instances may include the expanded form in the title
<abbr title="World Wide Web Consortium">W3C</abbr>
This means it will be available to all by default, without any need for
complicated solutions.
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
From: Birkir R. Gunnarsson
Date: Thu, Apr 16 2015 5:57AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
But does the abbr element work for keyboard only users?
How does it work visually?
If you put the abbreviation with a title, you would only see it with
either a screen reader that supports it, or if you hover over the term
with the mouse.
Basically, how does using the abbr element help over using just the
full phrase the first time around in the text, then using its
abbreviation .. such as
"Welcome to the website of the Central Intelligence Agency (CIA)"
...
"The role of the CIA is to ..."
vs.
"Welcome to the website of the <abbr>CIA</abbr> Central Intelligence Agency"
...
"The role of the <abbr title="Central Intelligence Agency">CIA</abbr> is to ...
If I were a keyboard only user, would the second markup help me
quickly locate the meaning of the abbreviation, more quickly than just
having spelled the phrase out in text?
I see the intent of the element, I guess it is all about browser
implementation/support.
Thanks
-Birkir
On 4/16/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> On 16 April 2015 at 11:29, < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Does anyone have suggestions for improvement?
>
>
> The first time an uncommon abbreviation is used in a page provide the
> expansion:
>
> example:
> <abbr>W3C</abbr> (World Wide Web Consortium)
>
>
> subsequent instances may include the expanded form in the title
> <abbr title="World Wide Web Consortium">W3C</abbr>
>
> This means it will be available to all by default, without any need for
> complicated solutions.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> > > > >
--
Work hard. Have fun. Make history.
From: Steve Faulkner
Date: Thu, Apr 16 2015 6:09AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
On 16 April 2015 at 12:57, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED =
> wrote:
> But does the abbr element work for keyboard only users?
> How does it work visually?
> If you put the abbreviation with a title, you would only see it with
> either a screen reader that supports it, or if you hover over the term
> with the mouse.
>
No it does not, which i why i suggested providing expansion in text the
first time, and followed saying that the abbr with title MAY be used in
subsequent intances on the page (useful to some, but not essential)
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
From: Nasrin.Saef
Date: Thu, Apr 16 2015 7:51AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
> The first time an uncommon abbreviation is used in a page provide the
> expansion:
> example:
> <abbr>W3C</abbr> (World Wide Web Consortium)
> subsequent instances may include the expanded form in the title <abbr title="World Wide Web Consortium">W3C</abbr>
> This means it will be available to all by default, without any need for complicated solutions.
That is actually done wherever feasible, so f.i. not in headings. Most of the abbreviations used in headings are repeated with their expanded form in the text right after, though. I see two drawbacks in leaving everything the way it currently is:
1) It's impossible to outrule human error; someone can always forget to mention the expanded form once, maybe because it's common in their field but not for the occasional layman looking for information.
2) I am such a layman in medicine issues. Before I started working here I knew pretty much none of the abbreviations frequently featured on our website, and even now if I try to read a text anywhere on it, chances are I forgot what most of them mean by time they're mentioned a second time. Without the mouseover I'd frankly just skip most of them and not really get the text, then realize I understood nothing, scroll back up, and try once or twice more.
I realize our js-implementation is only of limited use in that case too, because it's only supposed to show up the first time an abbreviation is used. But having no mechanism at all to offer the expanded form, on a site containing as many abbreviations as ours does, seems unsatisfactory as well. (Sadly "write simpler texts/use less abbreviations" isn't really an option.)
> But does the abbr element work for keyboard only users?
> How does it work visually?
> If you put the abbreviation with a title, you would only see it with either a screen reader that supports it, or if you hover over the
> term with the mouse.
Normally it only works on mouseover, yes, which is what we try to circumvent with a bit of scripting. It's not perfect - no js and it obviously doesn't work, and there's at least one bug in Chrome -, but overall it works like this: the first use of each abbreviation is included in the tab order (tabindex="0"), and when it has focus a small, pop-up like box appears above it and offers the expanded version.
Thanks for your replies!
Nasrin
From: Birkir R. Gunnarsson
Date: Thu, Apr 16 2015 8:00AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
How about you offer the user the ability to tab to each abbreviation.
You can have a preference radiobutton or button labeled
"use keyboard accessible abbreviations"
You could hide that button at the beginning of code order and make it
only visible if user uses the tab key, see the skip link technique at:
http://terrillthompson.com/blog/161
If user says "yes" add tabindex="0" to all technical terms and
implement an accessible tooltip (make sure the tooltip text is tied to
the focusable element using aria-described).
Give the user the chance to turn this functionality off (you can use a
toggle button for the setting .. a button with a visible class and
aria-expanded attribute to match).
This way you offer the functionality when needed, but users can turn
it off if it interferes with their navigation of the site, if their
primary purpose is to get to a control, not read or understand an
article.
On 4/16/15, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
>> The first time an uncommon abbreviation is used in a page provide the
>> expansion:
>> example:
>> <abbr>W3C</abbr> (World Wide Web Consortium)
>> subsequent instances may include the expanded form in the title <abbr
>> title="World Wide Web Consortium">W3C</abbr>
>> This means it will be available to all by default, without any need for
>> complicated solutions.
>
> That is actually done wherever feasible, so f.i. not in headings. Most of
> the abbreviations used in headings are repeated with their expanded form in
> the text right after, though. I see two drawbacks in leaving everything the
> way it currently is:
>
> 1) It's impossible to outrule human error; someone can always forget to
> mention the expanded form once, maybe because it's common in their field but
> not for the occasional layman looking for information.
>
> 2) I am such a layman in medicine issues. Before I started working here I
> knew pretty much none of the abbreviations frequently featured on our
> website, and even now if I try to read a text anywhere on it, chances are I
> forgot what most of them mean by time they're mentioned a second time.
> Without the mouseover I'd frankly just skip most of them and not really get
> the text, then realize I understood nothing, scroll back up, and try once or
> twice more.
> I realize our js-implementation is only of limited use in that case too,
> because it's only supposed to show up the first time an abbreviation is
> used. But having no mechanism at all to offer the expanded form, on a site
> containing as many abbreviations as ours does, seems unsatisfactory as well.
> (Sadly "write simpler texts/use less abbreviations" isn't really an
> option.)
>
>> But does the abbr element work for keyboard only users?
>> How does it work visually?
>> If you put the abbreviation with a title, you would only see it with
>> either a screen reader that supports it, or if you hover over the
>> term with the mouse.
>
> Normally it only works on mouseover, yes, which is what we try to circumvent
> with a bit of scripting. It's not perfect - no js and it obviously doesn't
> work, and there's at least one bug in Chrome -, but overall it works like
> this: the first use of each abbreviation is included in the tab order
> (tabindex="0"), and when it has focus a small, pop-up like box appears above
> it and offers the expanded version.
>
> Thanks for your replies!
> Nasrin
> > > > >
--
Work hard. Have fun. Make history.
From: Nasrin.Saef
Date: Thu, Apr 16 2015 8:25AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
Thank you, I can definitely work with that idea. It sounds like a pretty good compromise!
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag von Birkir R. Gunnarsson
Gesendet: Donnerstag, 16. April 2015 16:00
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Keyboard accessibility of abbreviations
How about you offer the user the ability to tab to each abbreviation.
You can have a preference radiobutton or button labeled "use keyboard accessible abbreviations"
You could hide that button at the beginning of code order and make it only visible if user uses the tab key, see the skip link technique at:
http://terrillthompson.com/blog/161
If user says "yes" add tabindex="0" to all technical terms and implement an accessible tooltip (make sure the tooltip text is tied to the focusable element using aria-described).
Give the user the chance to turn this functionality off (you can use a toggle button for the setting .. a button with a visible class and aria-expanded attribute to match).
This way you offer the functionality when needed, but users can turn it off if it interferes with their navigation of the site, if their primary purpose is to get to a control, not read or understand an article.
From: Jim Allan
Date: Thu, Apr 16 2015 9:25AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
I would also file a bug on all of the browsers. keyboard access to
abbreviations and such should be a browser function. There should not be a
need for thousands of authors to code some stuff that should be a function
of the browser.
Jim
On Thu, Apr 16, 2015 at 5:29 AM, < = EMAIL ADDRESS REMOVED = > wrote:
> Hi List,
>
> I'm currently trying to improve the keyboard accessibility of our website
> and recently decided to tackle abbreviations. According to the German
> accessibility regulations (and I'm sure there are equivalent success
> criteria in the WCAG) all functionality must be accessible by keyboard,
> and the expanded form of all abbreviations must be accessible to all users.
>
> To achieve this, we set up this javascript solution:
> https://jsfiddle.net/saenas/un40y5ey/
>
> But while it should fulfill the SC, we're not sure how good it is from a
> usability viewpoint. Since we provide medical information, there are a lot
> of abbreviations on our website, and implementing this solution (or any
> like it, really) forces keyboard users to tab a lot more. Additionally,
> while it is supposed to only expand the first instance of each abbreviation
> per page, this mechanism doesn't work for the navigation and the sidebar -
> so an abbreviation that is present in each element would be expanded three
> times.
> For reference, here is a link to one of our pages that contains LOTS of
> abbreviations: http://www.dimdi.de/static/de/klassi/index.htm
>
> That's why I'd like to ask keyboard users here: what do you think of such
> a solution? Do you think it would improve your experience or make it worse?
> Does anyone have suggestions for improvement?
>
> Thank you for your feedback!
> > > > >
--
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>;Jim Allan,
Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
From: deborah.kaplan
Date: Thu, Apr 16 2015 9:53AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
On Thu, 16 Apr 2015, = EMAIL ADDRESS REMOVED = wrote:
> 1) It's impossible to outrule human error; someone can always forget to mention the expanded form once, maybe because it's common in their field but not for the occasional layman looking for information.
True, and usually I am all about "give everything to the keyboard only users."
But in all cases, be aware of what limits to the acronym expansion are provided to the users without disabilities, as well. If the text corresponds to anything which is also provided as printouts, then readers of the paper version also don't have access to the expanded acronym beyond the first, explicit expansion. The W3C (World Wide Web Consortium) followed by "W3C" example is ubiquitous in print publishing. Online, I suspect (though I have no evidence) most sighted users are unlikely to click on acronym expansions even if they don't know their meaning.
And of course, while you're talking about jargony medical terms, it's also important not to get hung up on NASA, sonar, WWW, etc,or all of the other acronyms which most people know by acronym and rarely by expension.
So it sounds like you're doing the right thing here, with a very specific medical jargon set! But remember that there are appropriate cases not to expand.
Deborah Kaplan
From: Moore,Michael (DARS)
Date: Thu, Apr 16 2015 10:51AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
And while we are at it can we get more bug fixes reported to the screen reader folks to recognize and indicate content inside of <ins> and </del>. I have reported this for years to no effect.
Mike Moore
Accessibility Coordinator,
Texas Department of Assistive and Rehabilitative Services
(512) 424-4159 (Office)
(512) 574-0091 (Cell)
From: Scott González
Date: Thu, Apr 16 2015 11:45AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
Regarding <ins> and <del>, I've seen this CSS recommendation before:
@media braille, embossed, speech {
del:before { content: "Deleted: "; }
del:after { content: " (End of deletion.) "; }
}
del:hover { text-decoration: none; }
ins { text-decoration: none; border-bottom: dashed green 2px; }
On Thu, Apr 16, 2015 at 12:51 PM, Moore,Michael (DARS) <
= EMAIL ADDRESS REMOVED = > wrote:
> And while we are at it can we get more bug fixes reported to the screen
> reader folks to recognize and indicate content inside of <ins> and </del>.
> I have reported this for years to no effect.
>
> Mike Moore
> Accessibility Coordinator,
> Texas Department of Assistive and Rehabilitative Services
> (512) 424-4159 (Office)
> (512) 574-0091 (Cell)
>
>
From: Moore,Michael (DARS)
Date: Thu, Apr 16 2015 12:13PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
It's a nice idea but screen reading software (JAWS) does not pick up content added through before and after. I just confirmed running JFW 16 on FF latest release and IE 9 (don't ask). I will repeat the tests with NVDA, Window Eyes, and VoiceOver later but I don't hold out much hope. I tested with and without the media designation.
Mike Moore
Accessibility Coordinator,
Texas Department of Assistive and Rehabilitative Services
(512) 424-4159 (Office)
(512) 574-0091 (Cell)
From: Jonathan Avila
Date: Thu, Apr 16 2015 12:18PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
> @media braille, embossed, speech { del:before { content: "Deleted: "; } ...
The challenge with this CSS is that you have to have a user agent/AT combination that support the speech CSS media type and supports the CSS content property.
Jonathan
--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Jonathan Avila
Date: Thu, Apr 16 2015 12:30PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
> ). I will repeat the tests with NVDA
NVDA in Firefox will announced pseudo content.
Jonathan
--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: _mallory
Date: Thu, Apr 16 2015 1:37PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
On Thu, Apr 16, 2015 at 11:53:23AM -0400, = EMAIL ADDRESS REMOVED = wrote:
> If the text corresponds to anything which is also provided as printouts, then readers of the paper version also don't have access to the expanded acronym beyond the first, explicit expansion.
When I worked in insurance, also with many abbreviations, we used
a CSS style to expand abbreviations on print.
The HTML had something like
<span class="tip" title="Wettelijke aansprakelijkheidsverzekering">WA</span>
In the print stylesheet, we had something like
.tip:after {
content: " ("attr(title)")";
and other styles like bolding
}
Resulting in the screen showing "WA"
and the printout, on the fist instance, showing
"WA (Wettelijke aansprakelijkheidsverzekering)"
We did this for any external URLs that were on the website so people
could see the URLs after print.
On another note, I like Birkir's idea of being able to turn on or
off the tab-expansion.
_mallory
From: _mallory
Date: Thu, Apr 16 2015 1:39PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
On Thu, Apr 16, 2015 at 06:18:14PM +0000, Jonathan Avila wrote:
> > @media braille, embossed, speech { del:before { content: "Deleted: "; } ...
>
> The challenge with this CSS is that you have to have a user agent/AT combination that support the speech CSS media type and supports the CSS content property.
>
Better to just use offscreen text, since not all dels mean
deleted anyway, right?
(in ecommerce it's common with old prices)
_mallory
From: Moore,Michael (DARS)
Date: Thu, Apr 16 2015 2:01PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
Thanks, I will open a bug report with Freedom Scientific.
Mike Moore
Accessibility Coordinator,
Texas Department of Assistive and Rehabilitative Services
(512) 424-4159 (Office)
(512) 574-0091 (Cell)
From: Graham Armfield
Date: Thu, Apr 16 2015 2:31PM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
Actually I've been testing with NVDA and Firefox just this week and NVDA
2014.4 does seem to be voicing content in the :before and :after
definitions.
This is a good thing, but also a bad thing in that you discover that many
icons from icon fonts are delivered to the page in those constructs. So you
can get some seemingly random characters being voiced. For instance S S S S
S meant that a product had a five star review.
Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>
On Thu, Apr 16, 2015 at 7:13 PM, Moore,Michael (DARS) <
= EMAIL ADDRESS REMOVED = > wrote:
> It's a nice idea but screen reading software (JAWS) does not pick up
> content added through before and after. I just confirmed running JFW 16 on
> FF latest release and IE 9 (don't ask). I will repeat the tests with NVDA,
> Window Eyes, and VoiceOver later but I don't hold out much hope. I tested
> with and without the media designation.
>
> Mike Moore
> Accessibility Coordinator,
> Texas Department of Assistive and Rehabilitative Services
> (512) 424-4159 (Office)
> (512) 574-0091 (Cell)
>
>
From: Patrick H. Lauke
Date: Thu, Apr 16 2015 2:39PM
Subject: Re: CSS generated content (wasKeyboard accessibility of abbreviations)
← Previous message | Next message →
On 16/04/2015 22:31, Graham Armfield wrote:
> Actually I've been testing with NVDA and Firefox just this week and NVDA
> 2014.4 does seem to be voicing content in the :before and :after
> definitions.
>
> This is a good thing, but also a bad thing in that you discover that many
> icons from icon fonts are delivered to the page in those constructs. So you
> can get some seemingly random characters being voiced. For instance S S S S
> S meant that a product had a five star review.
That's why, in Bootstrap for instance, we add aria-hidden=true to the
element with the generated content (though I seem to recall one
particular browser/SR combo ignored this...Firefox+NVDA I think?).
http://getbootstrap.com/components/#glyphicons-examples
See also http://tink.uk/accessibility-support-for-css-generated-content/
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Bourne, Sarah (ITD)
Date: Fri, Apr 17 2015 6:29AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | Next message →
Another option, which popped into my head reading Birkir's suggestion, would be to add a button at the top of each page that would expand all abbreviations on the page, and toggle them back. That would make it available to all users, if and when they want it.
If my skills matched my imagination, I'd make a browser extension that did that.
sb
Sarah E. Bourne
Director of IT Accessibility, MassIT
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/MassIT
From: Nasrin.Saef
Date: Tue, Apr 21 2015 9:51AM
Subject: Re: Keyboard accessibility of abbreviations
← Previous message | No next message
Thank you to everyone for your input! I was out of the office since Thursday afternoon, otherwise I'd have replied earlier.
Following Birkir's suggestion I updated the page with a toggle to shut the functionality on or off. Said toggle will appear along with the "skip to content" link and will be placed right after it in the tab order. He also recommended adding several aria attributes, which I'll have to look into; the toggle button should be fine since at its base it is a normal html checkbox, but the popup-boxes will probably warrant a logical link to the HTML elements they describe.
So, this is what I ended up with: http://jsfiddle.net/saenas/un40y5ey/8/
Deborah:
> And of course, while you're talking about jargony medical terms, it's also important not to get hung up on NASA, sonar, WWW,
> etc,or all of the other acronyms which most people know by acronym and rarely by expension.
I definitely agree with that. Before anything like the solution linked above is implemented I'll talk to my colleagues about weeding out some of the abbreviations (like PDF, kB etc.) that really don't need to be expanded for any user.
Jim and Sarah:
> I would also file a bug on all of the browsers. keyboard access to abbreviations and such should be a browser function.
> There should not be a need for thousands of authors to code some stuff that should be a function of the browser.
/
> If my skills matched my imagination, I'd make a browser extension that did that.
Full browser implementation or at least an extension for a toggle to expand the abbreviations would definitely be a better solution. Guess after spending the time already to piece together my attempt at a solution I might as well look up how browser bug reporting works when I have a bit of time.