W3C home > Mailing lists > Public > public-pfwg@w3.org > February 2015

RE: Experiments with ARIA Tooltips based on the last APG call

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Date: Wed, 18 Feb 2015 18:51:31 +0000
To: Birkir Gunnarsson <birkir.gunnarsson@deque.com>, "public-pfwg@w3.org" <public-pfwg@w3.org>
Message-ID: <BY2PR03MB347EB94C70B264B775B3977982C0@BY2PR03MB347.namprd03.prod.outlook.com>
No problem, I'm not sure how much point there is to making the beginning and ending boundaries of a Tooltip node conveyable via aria-label or aria-labelledby, since it's designed to disappear when focus moves away from the triggering element anyway, so it will disappear if you try to arrow to it in NVDA for example since onBlur is automatically fired then.

I added role=region and an explicit label in this case simply because it adds context in JAWS, which I like the sound of and it identifies the purpose of the content, but this is really only valid in JAWS where onBlur is not automatically fired when arrowing away from the triggering element. This is just a matter of personal design preference however.

This technique is mainly helpful for inline error handling though, such as at
Where, if using JAWS for example, you can press Control+Insert+R to open a list of named regions and jump to the location of an error on the page.

Since aria-describedby is useless in this case because the errors only appear after focus moves away from the relevant form field, an ARIA Tooltip isn't used here, just a standard live region via aria-live=polite, which of course only now appears to work reliably in Firefox and not in IE...

For a tooltip to be accessible using a screen reader, the content needs to be announced when the tooltip is rendered, which is bound when aria-describedby is set and points to the tooltip. I believe this is when the relevant event is fired in the browser which ATs can listen for.

I just tested this using the latest version of iOS, and tooltips are not announced when they appear and they disappear when you try to move focus to them, so they are not accessible on iOS via touch. I'm not sure how this can be approached, since the act of moving reading focus anywhere causes the onBlur/onMouseOut to fire, and thus automatically closes the tooltip. I can disable this for touch users, but how then is the tooltip to be closed?

I think the spec text regarding a supplement to the normal tooltip functionality is confusing too, since you would not want both a dynamic tooltip to appear as well as a browser tooltip via the title attribute to be displayed at the same time.

-----Original Message-----
From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
Sent: Wednesday, February 18, 2015 9:52 AM
To: Bryan Garaventa; public-pfwg@w3.org
Subject: RE: Experiments with ARIA Tooltips based on the last APG call


Excellent work as always, particularly like the Douglas Adams reference.
My brief testing on Jaws and NVDA with IE/FF confirms your findings.
I even set Jaws verbosity to "beginner" and it had no effect on the tooltip announcement, or lack thereof in IE.
I notice that you resort to using div with aria-label="tooltip" and role="region" as a container for the actual tooltip container.
This matches with my observations that role="tooltip" is not given any special treatment by any screen reader I have tested.
3 questions:
1. What is the desireable behavior of screen readers for containers with role="tooltip"?
Screen readers should announce the word "tooltip" and then its content, followed by the tooltip content or other accessible name, if provided via aria-label or aria-labelledby?
That is my thinking at least.

2. Have you tested this on Voiceover, which has a native 7 second delay for announcing aria-describedby content. Does the built-in delay add to that time (I think it should, based on the spec)?
3. I am not sure exactly wat this sentence in the spec means:
"The use of a WAI-ARIA tooltip is a supplement to the normal tooltip behavior of the user agent"
Is this referring to the title attribute, .. or what is the normal behavior of tooltips in browsers? I see this is referenced in the meeting minutes, I may just have to go explore. Unfortunately I missed that meeting on Monday but will join you for next time.

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Wednesday, February 18, 2015 12:32 PM
To: public-pfwg@w3.org
Subject: Experiments with ARIA Tooltips based on the last APG call

I was running some compatibility tests for ARIA Tooltip support based on the last APG call, and found that it still isn't supported well.

I've updated the Tooltip module for this purpose, at http://whatsock.com/tsg/Coding%20Arena/Tooltips/Tooltip%20(Internal%20Conten
Which supports focus ability as before, but also a 1.5 second (adjustable) delay, and Escape as a method for dismissing the tooltip.

The premise being, that a dynamic tooltip container may actually not exist in the DOM until it is rendered, which is what is happening on this page.
This means that, aria-describedby must be implemented to point to the role=tooltip container after it is rendered to avoid pointing to a null reference, this being after 1.5 seconds in this case.

Again, as with live region support, this appears to work perfectly in Firefox using the leading screen readers JAWS and NVDA, but doesn't work reliably in IE using either JAWS or NVDA.
Received on Wednesday, 18 February 2015 18:52:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:23 UTC