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

RE: Is there a public list of events that should fire when ARIA is used?

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Date: Mon, 23 Feb 2015 06:55:39 +0000
To: Richard Schwerdtfeger <schwer@us.ibm.com>, Dominic Mazzoni <dmazzoni@google.com>
CC: "public-pfwg@w3.org" <public-pfwg@w3.org>
Message-ID: <BY2PR03MB3474FA840DEC3BA45A79C0698290@BY2PR03MB347.namprd03.prod.outlook.com>
Thanks, the reason why I bring up this particular use case, is because we have been working on the ARIA Tooltip design pattern in the ARIA APG group, and it calls for a time delay between the time that the element is triggered and when the tooltip is displayed visually.

When this is the case, there is no guarantee that the tooltip container will exist in the DOM until it is actually rendered, such as element.appendChild or the use of innerHTML in some cases.

When this happens, there is no way to set aria-describedby in advance, because there is nothing to point it to.

So, in this case, how are ARIA Tooltips to be made accessible, where the tooltip text will be announced reliably when it appears?

Should there be two different design patterns for tooltips, one for when they are always in the DOM, and another for when they are not? E.G One requiring the use of aria-describedby+role=tooltip, and another that should not use this combination because it doesn’t work?

It doesn’t appear that the spec text for role=tooltip is enough to explain this properly.

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Sunday, February 22, 2015 4:50 PM
To: Dominic Mazzoni
Cc: Bryan Garaventa; public-pfwg@w3.org
Subject: Re: Is there a public list of events that should fire when ARIA is used?

Hi Dominic,

I don't believe and event fires for that. That said, with MSAA/IA2 you will get a relation set and an accDescription applied. So, only the description change event is really necessary. I don't believe we created a describedby event change for just the reason you highlighted. Descriptions constitute secondary information and are not typically spoken automatically.


Rich Schwerdtfeger

[Inactive hide details for Dominic Mazzoni ---02/22/2015 12:19:47 PM---If the description is exposed in the "description" field]Dominic Mazzoni ---02/22/2015 12:19:47 PM---If the description is exposed in the "description" field when you explore it with a MSAA tool, then

From: Dominic Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Cc: "public-pfwg@w3.org<mailto:public-pfwg@w3.org>" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date: 02/22/2015 12:19 PM
Subject: Re: Is there a public list of events that should fire when ARIA is used?


If the description is exposed in the "description" field when you explore it with a MSAA tool, then EVENT_OBJECT_DESCRIPTIONCHANGE would be the event that should fire.

However, if aria-describedby points to another element with visible text on the page, then it's exposed via IAccessibleRelation with the code IA2_RELATION_DESCRIBED_BY. I can't find an event that's supposed to fire if that property changes. Maybe someone else knows?

In either case, it's not clear to me that dynamically changing the accessible description - by any means - should necessarily cause a screen reader to speak the description. In general the only standard way to get a screen reader to speak something asynchronously (i.e. not in response to a user event) is with a live region. Any other case where it speaks something is typically dependent on the screen reader and not standardized.

- Dominic

On Sat, Feb 21, 2015 at 3:39 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
I do have one question though, it looks like aria-describedby isn’t listed as firing any event when changed programmatically. Does this actually fire any event when this occurs?

I’m referring to the scenario when an element has focus, such as a form field, and within a certain time delay (e.g 1.5 seconds), a tooltip is programmatically displayed by inserting it into the DOM, where aria-describedby is then set on the element that has focus to point to the newly displayed tooltip.

This scenario would also occur for dynamically updating tooltips, such as when typing into a form field that rendered different tooltips as you type in order to shape the user’s input responses.

Does the modification of aria-describedby then fire a specific event when this occurs?

From: Dominic Mazzoni [mailto:dmazzoni@google.com<mailto:dmazzoni@google.com>]
Sent: Friday, February 20, 2015 11:24 PM
To: Bryan Garaventa
Cc: public-pfwg@w3.org<mailto:public-pfwg@w3.org>
Subject: Re: Is there a public list of events that should fire when ARIA is used?

Hi Bryan,

The WAI-ARIA User Agent Implementation Guide includes a section on what events are supposed to be fired in response to ARIA changes: http://www.w3.org/TR/wai-aria-implementation/#mapping_events

If you're testing IE, the table should be sufficient. However if you're testing Firefox or Chrome, I'm not sure you can use Accessible Event Watcher because I think it only knows about MSAA and UIA events, but Firefox and Chrome also send IAccessible2 events.

- Dominic

On Fri, Feb 20, 2015 at 9:10 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

Hopefully somebody can point me in the right direction here.

I'm experimenting with Accessible Event Watcher, at

In order to get a better understanding of which events fire when ARIA is used on the Windows OS, and when this happens such as when various properties and states change during interaction.

However, I'm not sure which events I should be checking for, what their names are, and which ARIA changes should be triggering these.

Is there a public list of events somewhere that describes which events should fire and when that I could review in order to understand these things better? I expect this may be platform specific, but any resource would be helpful.


(image/gif attachment: image001.gif)

Received on Monday, 23 February 2015 06:56:11 UTC

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