W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > January to March 2010

[ARIA] Popups

From: Terrill Thompson <tft@u.washington.edu>
Date: Sun, 21 Mar 2010 21:39:36 -0700
To: "public-pfwg-comments@w3.org" <public-pfwg-comments@w3.org>
Message-ID: <14C6C8313F1842459FAAD0B3FEB9E42C41EC6427@ads-mbx-02.exchange.washington.edu>

Please forgive my late comments. Gregory Rosmaita said it wasn't too late. 

I've been struggling recently with how best to apply ARIA to the use case of a hidden informational popup that is made visible by user action. Netflix..com provides a good example of this type of behavior (hovering over a movie results in a popup being displayed), as does my own test page:

When a user triggers the pop-up, the desired effect is for screen readers to automatically alert the user that the popup has appeared, and temporarily move their focus to that popup. When they close the popup, their focus should return to the originating trigger element. 
Specific reasons for my confusion: 

1. This specific use case does not seem to be addressed within the WAI-ARIA Authoring Practices 1.0. Might I request that it be added? 

2. aria-haspopup

This would seem by name to be an applicable property to the use case described above, but as I look at the description it isn't clear to me whether it's applicable or not. 

The definition first states "Indicates that the element  has a popup context menu or sub-level menu." This would seem to suggest that this property only applies to menus. However, the next part of the definition ("This means that activation renders conditional content") seems to be defining "popup" more loosely. 

Currently, if a link includes aria-haspopup="true", NVDA identifies it as a "Submenu link". If this is correct implementation, that reinforces that aria-haspopup does not include popups that are not part of a menu system. 

3. aria-hidden

The intent of aria-hidden is relatively clear from the spec. However, the second paragraph of the definition once again refers explicitly to menus. "If a menu is only visible after some user action..." Should "menu" be replaced with "element" in order to be consistent with the first paragraph? 

In fact, I recommend that the entire ARIA spec be checked for menu bias. Are there some roles, states, and/or properties that are being defined explicitly in terms of their applicability to rich menus, when in fact they might have more general applicability?  

4. aria-owns vs. aria-controls

It seems to me that one of these properties may be applicable to the popup use case described above. However, I'm not clear how the two properties differ from one another. Both reference the other, but no explanation is given as to their relationship. Aria-controls includes examples. Perhaps if aria-owns also included examples, the difference between these properties would be more clear. Another alternative would be to include text that specifically describes the differences, similar to text that currently explains the difference between aria-describedby and aria-labelledby.

5. Definition of "Live Regions"

What exactly is a live region? The term is used repeatedly throughout the ARIA spec, but nowhere do I see it actually defined within the spec. The only definition I could find outside the spec is in section 5.2 of WAI-ARIA Authoring Practices 1.0:

There, it is said that "Live regions are part of a Web page that the author expects to change". The phrase "Live Regions" in that definition is a link to the ARIA spec, to an id that doesn't seem to exist:  

Given this limited definition, I wonder whether the popup div in my popup use case might be a live region, and therefore all live region properties, including aria-live="assertive", would apply, and would result in the desired effect as describe at the top of this message. If a popup div is not a live region, why not? What criteria does it fail to meet? 


Terrill Thompson
University of Washington
Received on Monday, 22 March 2010 04:43:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:02 UTC