E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Sylvia Richardson
Date: Mon, Mar 30 2015 11:55AM
Subject: Accessible Tooltips with HTML-content
No previous message | Next message →

Does anyone have recommendations for screen reader- and keyboard-friendly tooltips that meet the standards set in WAI-ARIA 1.0 Authoring Practices<http://www.w3.org/TR/wai-aria-practices/#tooltip>; and allow HTML-formatted content? Ideally, I'd like to find an existing library rather than reinvent the wheel, but we can write custom code if we need to.

A little background here: I work for a health insurance company. We want to have definitions of complex terms, like co-insurance, that appear on mouseover/keyboard focus. The code would need to work with a <span> or similar element as the parent. Unfortunately, most of the examples I have seen only work smoothly with <input> elements. Additionally, we need to be able to include HTML-formatted content in the tooltip itself, generally lists.

The best luck I have had so far is using qTip2<http://qtip2.com/>; with some customizations to support keyboard handlers, but the behavior is not as smooth as I would like. Specifically, in Firefox with NVDA or Jaws, tabbing to an element with a tooltip reads the tooltip but not the parent text (possibly due to using role="alert" instead of tooltip).

Any help you can offer would be appreciated.

Sylvia Richardson | Web Accessibility Advisor
= EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >


Blue Cross and Blue Shield of North Carolina

Confidentiality Notice: This message is intended only for the use of the individual or entity to which it is addressed. This communication may contain individual protected health information ("PHI") that is subject to protection under state and federal laws, or other privileged, confidential or proprietary information of Blue Cross and Blue Shield of North Carolina that may not be further disclosed. If you are not the intended recipient, or the employee or agent responsible for delivering this communication to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you.

From: Bryan Garaventa
Date: Tue, Mar 31 2015 9:52PM
Subject: Re: Accessible Tooltips with HTML-content
← Previous message | Next message →

Hello,
I have programmed the Tooltip module within the TSG archive to do what you are asking, with strict adherence to the spec regarding functionality and accessibility. This can be downloaded at
https://github.com/accdc/tsg

Contained within the folder
Coding ArenaTooltips

It works on form fields, but can also be used on any other form of active element, which you can experiment with by changing the code and seeing what happens.

All the best,
Bryan

From: Birkir R. Gunnarsson
Date: Wed, Apr 01 2015 12:54AM
Subject: Re: Accessible Tooltips with HTML-content
← Previous message | Next message →

One thing to keep in mind here:
If the user may wan to carefully review the tooltip content (and if
you want it formatted with html it sounds like this is info the users
may want to review carefully, not just hear it announced on the fly) a
pop-up dialog triggerable by wih he keyboard is probably a better
solution for the user.
You could put a clickable help icon with suitable alt text next to the
term itself that, when activated, brings up a modal dialog with the
information.
For tooltips that are simple and short, using an accessible alert
combined with keyboard focus and aria-describedby work fine, but for
the more complex info that user needs to read more than once or needs
to memorize, make sure they can bring up that information, review it
until they feel confident they understand it, and then dismiss it. A
modal dialog would be just the thing for that.
Cheers
-B


On 3/31/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
> I have programmed the Tooltip module within the TSG archive to do what you
> are asking, with strict adherence to the spec regarding functionality and
> accessibility. This can be downloaded at
> https://github.com/accdc/tsg
>
> Contained within the folder
> Coding ArenaTooltips
>
> It works on form fields, but can also be used on any other form of active
> element, which you can experiment with by changing the code and seeing what
> happens.
>
> All the best,
> Bryan
>
>
>
>

From: Sylvia Richardson
Date: Wed, Apr 01 2015 7:18AM
Subject: Re: Accessible Tooltips with HTML-content
← Previous message | Next message →

Thanks! I like that idea, and it is something we had considered as an alternate solution. Some of our pages have several tooltips, so making the content optional is probably a good idea from a usability perspective. In my quick tests, role="dialog" or role="alertdialog" plus some focus management seems to work fairly well.

For a help icon, does anyone have suggestions for short alt text that would make it clear the user can open a dialog? "Help" seems too vague, but something like "Read definition" might become annoying if repeated.

Thanks,

Sylvia

From: Birkir R. Gunnarsson
Date: Wed, Apr 01 2015 8:25AM
Subject: Re: Accessible Tooltips with HTML-content
← Previous message | No next message

A somewhat, but not entirely, useful solution is to put ellipsis "..."
after the word
"help..."
traditionally putting "..." has indicated that activating the item
opens a dialog (see "save as..." in Windows apps), however screen
readers often do not announce punctuation so this is lost on many
users.
There are on-going discussions for ARIA 1.1 to expand the
aria-haspopup attribute with a list of options to indicate type of
widget (menu, dialog, definition..) but that is still at the
conceptual consideration stage.

For one website that had a lot of definition terms I was playing
around with simply putting instructions at the top saying (use the tab
key to discover definition terms, use enter to open help for that
definition), and then I implemented clickable divs or spans with
tabindex but no role.
I did this to keep the screen reading seamless (enabling screen
readers to read text without interrupting announcements of embedded
links or buttons).
Think:
<code>
<p>My favorite
<span tabindex="0" onClick="processclick(event)"
onKeyUp="processkey(event)" class="focus">IRA</span>
provider is Lost Profits LLLC</p>
</code>

This worked fine, user was able to read the text uninterrupted, but
then user had to use his tab key to look for definition terms and
activate them to review a modal dialog with definitions.
Also this is technically a violation of 4.1.2 since the clickable
element has no "role".
html5 has some tags, dfn and abbr, but assistive technology support
for them has not been overwhelming and besides that you would not be
able to format the title with html.


My solution was somewhat hacky.
If there are clear instructions to users about the type of interaction
I felt this was acceptable, but I would not necessarily recommend this
as a standard best practice.



On 4/1/15, Sylvia Richardson < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks! I like that idea, and it is something we had considered as an
> alternate solution. Some of our pages have several tooltips, so making the
> content optional is probably a good idea from a usability perspective. In my
> quick tests, role="dialog" or role="alertdialog" plus some focus management
> seems to work fairly well.
>
> For a help icon, does anyone have suggestions for short alt text that would
> make it clear the user can open a dialog? "Help" seems too vague, but
> something like "Read definition" might become annoying if repeated.
>
> Thanks,
>
> Sylvia
>
>
>