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

RE: Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

From: Terrill Thompson <tft@u.washington.edu>
Date: Fri, 23 Jul 2010 11:55:08 -0700
To: PFWG Public Comments <public-pfwg-comments@w3.org>
Message-ID: <14C6C8313F1842459FAAD0B3FEB9E42C51FD5735@ads-mbx-02.exchange.washington.edu>
Comment 326: Popups - aria-haspopup

Thanks. I accept this response. tt

-----Original Message-----
From: Janina Sajka [mailto:janina@a11y.org] 
Sent: Thursday, June 17, 2010 11:29 AM
To: Terrill Thompson
Cc: PFWG Public Comments
Subject: Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Comment 326: Popups - aria-haspopup
Date: 2010-03-23
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JanMar/0045.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-haspopup (property) <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#aria-haspopup>
Status: Alternate action taken

Your comment:
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

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. 

aria-haspopup 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.

Response from the Working Group:
aria-popup is used only to to indicate a relationship to a pop up menu as
platform accessibility APIs provide a property for it. The ARIA
specification is very clear on this. 

A window appearing as the result of an action does not necessarily mean it
is a pop up. For example, a dialog could be considered to be a pop-up give
the terms you have described. However, what causes the screen reader to
speak it is the fact that a dialog is created, it has a label, and there is
an element with focus that needs to be announced. 

In your example, a properly implemented dialog would:

- have a label which would the dialog would reference using
- have an aria-describedby reference to the message so that a screen
reader would to read it when the dialog is launched 
- Place focus on the link so that the user has a point of reference within
the dialog box. 

See the text on how to implement dialog boxes in the WAI-ARIA authoring
practices guide:






Also, while your example should be a dialog, you are mistaken in the
assumption that the Netflix popup is the same. The Netflix example
mentioned in the comment should be a popup or a tooltip, not a dialog.

1. It is triggered by focus or mouse hover, rather than by direct user

2. It should not achieve focus by default. If Netflix implemented its info
popups as modal dialogs, the Netflix site would be almost very unusable to
a screen reader user, because they would be forced to dismiss a dialog upon
every step through a list of movies. This should either be a popup
associated with aria-owns, and the AT should provide a way for the user to
navigate the relationship, or it should be a tooltip associated with
Received on Friday, 23 July 2010 18:56:41 UTC

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