Add accessibility features

[stevenbenner]

Currently tooltips are not accessible to visually impaired users or users who navigate with the keyboard. Accessibility features should be added to make tooltips useful to those users.

• It has been suggested that PowerTip implement ARIA standards (intro, spec) similar to this example.
• Tooltips should open on focus and close on blur to support keyboard navigation.

[stevenbenner]

Keyboard navigation support added in commit 85da84db26bc0e6b3ea2b0b9d79061120ba26b25.

Still have to determine if it is possible to implement ARIA, and if so, how best to do it.

[stevenbenner]

It does not appear that I can implement ARIA standards without a fundamental change to how the tooltip system works.

Right now there is only one tooltip div used, it would be preferable for the ARIA implementation that each tooltip item have it's own div to preserve a fixed aria-describedby relationship. But my testing with JAWS shows that this isn't an absolute requirement.

Unfortunately, the combination of the single-div system and the nice queue and fade system simply wont work for a aria-describedby relationship. If the cursor reaches an element with a tooltip while another tooltip is open, then the content of the tooltip div will still be that of the last tooltip when the screen reader processes the ARIA attributes (due to the tooltip gracefully closing).

The only solution that I can think of right now is to create a new tooltip div for each tooltip item.

[mdarens]

I don't have JAWs handy to test, but would setting aria-live to polite or assertive on the tooltip work?

[stevenbenner]

Actually, it just might, if I combine the aria-live attribute with aria-describedby and don't set the reference until the tooltip content has loaded. I'll give it a shot after I finish the work for elastic tooltips.

[stevenbenner]

I still couldn't get it to work right.

The aria tags just don't seem to work as expected for the queued tooltips. I've tried various configurations of aria-live, aria-describedby, and aria-controls. None of them do what I would expect. The closest I can get is with a direct described by relationship, but if I tab from one tooltip element to another, then another, in rapid succession, JAWS will read the tooltip for the one I skipped over (because of the queued transition).

I've tried setting aria-busy during the tooltip transition, and resetting it when complete, but that doesn't seem to work at all. JAWS will never read the tooltips. Setting aria-describedby late has the same effect.

Even when I get it close to working JAWS says "Use JAWS key plus ALT plus R to read descriptive text", then it reads the descriptive text immediately anyway. I cannot figure out what is triggering JAWS to announce that, but the original ARIA example does not do that.

Working with JAWS and ARIA has been completely frustrating for me. I wish there was another decent screen reader that supported ARIA and didn't have a 40 minute timer (or cost $900). I need to setup JAWS on a virtual machine before I do any more work on this.

Right now it still looks like I will have to create a new tooltip div for each element if I want to support ARIA. But I really don't want to pollute the document with possibly hundreds of elements that may never be used if I can help it.

[chris-pearce]

Nice to see you're trying with ARIA, I've been looking for a new tooltip plugin and as usual none cater for ARIA or even the basics of accessibility e.g. keyboard support.

You don't need to create a separate div for each tooltip to get this to work for ARIA. Basically the ARIA that's needed is this:

Tooltip div:

• role="tooltip" (easy enough)
• a unique id (can do something like id="powertip-1", and just increment the number by 1 each time)

Tooltip trigger:

• aria-describedby="id-of-tooltip"

It's being done here: http://hanshillen.github.com/jqtest/#goto_tooltip, this a reputable source and a benchmark for me when trying to make jQuery plugin's more accessible.

Also you can try the free NVDA screen reader: http://www.nvda-project.org/. Testing the above example with NVDA works fine.

Be great if you could have a go at this as this is the best plugin I've seen so far and like you I'd rather not have seperate divs for each tooltip littered everywhere in my markup.

Cheers

[chris-pearce]

The example I provided above is based off the jQeury UI library: http://jqueryui.com/tooltip/.

[stevenbenner]

Thanks for the links and tips. I'll give that a shot and see if I can get it working.

There is one gotcha though, right now PowerTip uses the id for CSS targeting. If the id is no longer static then it would break existing PowerTip installations, so even if I can get this working it will have to wait until the 2.0 release because of the breaking changes.

Alternatively, I could add a div inside the #powertip div with the unique id, but that could also break some peoples styles.

I'll do some experimenting.

[chris-pearce]

No worries.

I see what you mean about the CSS hook, I'd move the CSS hook to a class anyway with ver 2.0 as id's should be avoided for CSS styling, this is advocated by most of the CSS experts out there e.g. Harry Roberts, Jonathan Snook, etc. I adhere to this also.

Be great to implement this as it would really make your already great plugin even more great, as I said accessibility is just not implemented into so many plugins out there and for some this is a deal breaker.

Cheers

[chris-pearce]

There's an open ticket over at Twitter Bootstrap to implement accessibility for their tooltip: https://github.com/twitter/bootstrap/issues/3535, the ticket provides a nice list of what needs to be done.

[speedplane]

I know it's a decade old, but accessibility features are more important now than ever. If there is any way I can help, would be happy to contribute.

[stevenbenner]

I would love to see screen reader support added.

It's actually quite embarrassing that it never got implemented, as it was something I had planned to add from the beginning. When I first tried to do this, the tooling implementing ARIA was so terrible to work with, the behavior so seemingly random, and the effects so inconsistent between screen reader programs. I just gave up after a while. It seemed that the requirements of PowerTip were incompatible with screen reader software implementing ARIA.

I hope it is better now, but I haven't been following the technology much in recent years. On Windows, it seems that NVDA has gained more traction, and JAWS less, which is good news if my previous experience still holds true.

If you're volunteering to try to get AIRA working, then I would gratefully accept. But I do have a couple requests:

1. If it looks like a big project then break it up into small pull requests with small changes and submit them as you make progress, rather than as one big collection of commits (so it's easy for me to code review and asses risk along the way).
2. If it will require breaking backwards compatibility (like the unique id problem mentioned above), please confirm with me before putting any time into it (because don't have plans for a new major version in the foreseeable future).

Right now PowerTip is basically in maintenance mode, since interest has dried up in favor of newer tech. So I want to keep changes low-risk and backwards compatible, that way I can roll out fixes to legacy users without requiring them to perform code rewrites to upgrade (which many will never do).