Response to your comments on WAI-ARIA 1.0 Authoring Practices

Dear Terrill Thompson:

Thank you for your comments on the 15 December 2009 Working Draft of
WAI-ARIA 1.0 Authoring Practices
(http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/). The Protocols
and Formats Working Group has reviewed all comments received on the draft.
We would like to know whether we have understood your comments correctly
and whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to us
by 2 July 2010 to say whether you accept them or to discuss additional
concerns you have with our response. If we do not hear from you by that
date, we will mark your comment as "no response" and close it. If you need
more time to consider your acknowledgement, please let us know. You can
respond in the following ways:

* If you have a W3C account, we request that you respond online at
http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=7;

* Else, by email to public-pfwg-comments@w3.org (be sure to reference our
comment ID so we can track your response). Note that this list is publicly
archived.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the archived
copy of your original comment on
http://lists.w3.org/Archives/Public/public-pfwg-comments/, and may also
include links to the relevant changes in the WAI-ARIA 1.0 Authoring
Practices editors' draft at
http://www.w3.org/WAI/PF/aria-practices/20100616/.

Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to 3.3.2 of
the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-pfwg-comments@w3.org. Formal objections will be reviewed during
the candidate recommendation transition meeting with the W3C Director,
unless we can come to agreement with you on a resolution in advance of the
meeting.

Thank you for your time reviewing and sending comments. Though we cannot
always do exactly what each commenter requests, all of the comments are
valuable to the development of WAI-ARIA 1.0 Authoring Practices.

Regards,

Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact


Comment 322: Popups
Date: 2010-03-23
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JanMar/0045.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 4.4. Popups and drop-downs <http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/#relations_haspopup>
Status: Answered question

-------------
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
page:
http://terrillthompson.com/ncaa/test.html

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. 

--------------------------------
Response from the Working Group:
--------------------------------
We have added an example of the usage of @aria-haspup to section "4.4.
Popups and drop-downs" of the WAI-ARIA Authoring Practices [1].  The
example is of a menubar, its menus, and a submenu.  The @aria-haspopup
property is used in the example only where a menu would be invoked, as
according to the ARIA specification [2].

The Netflix popup is an example of bubble help, and not of a menu.  The
@aria-haspopup property does not apply.  The closest ARIA role for this
popup is "tooltip" [3].

The intent of your show/hide text example is unclear, making it difficult
to advise what role to use here.  But, it is clear that the toggled text is
not a menu.  Because of that, the element that triggers showing the text
would not have an @aria-haspopup property.

[1]
http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/#relations_haspopup
[2]
http://www.w3.org/TR/2009/WD-wai-aria-20091215/states_and_properties#aria-haspopup
[3] http://www.w3.org/TR/2009/WD-wai-aria-20091215/roles#tooltip

----------------------------------------------------------------------


Comment 325: Popups - live regions
Date: 2010-03-23
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JanMar/0045.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 5.2.  Implementing Live Regions  <http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/#LiveRegions>
Status: Alternate action taken

-------------
Your comment:
-------------
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:
http://www.w3.org/WAI/PF/aria-practices/#LiveRegions

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:  
http://www.w3.org/TR/wai-aria/#liveregions

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? 

--------------------------------
Response from the Working Group:
--------------------------------
We have added a glossary definition for live region that is now referenced
throughout the specification. A pop-up is the direct result of a user
action and should not be marked as a live region. Popup's will be spoken
automatically provided that you have an element within it that has focus. 

Here is our glossary definition of a "live region":

Live regions are perceivable regions of a web page that are updated as a
result of an external event from areas of the page which have user focus.
These regions are not generally regions of the page that are updated as
result of a user interaction. This practices has become common place with
the growing use of Asynchronous JavaScript and XML (AJax). Examples of live
regions are chat logs or a sport scoring section that updates periodically
to reflect game statistics. Since these asynchronous areas may update
outside the user's area of focus, assistive technologies such as screen
readers have either been unaware of their existence or how to process them
for the user. WAI-ARIA has provided a collection of properties that allow
the author to identify these live regions  and how to process them:
aria-live, aria-relevant, aria-atomic, and aria-busy.  WAI-ARIA has a
collection of pre-defined roles that are forms of live regions.

As for your pop-up use case we need more information. It could be a
tooltip, a dialog, or a menu or perhaps not a pop-up at all. The aria
specification is clear in that aria-popup only refs to menus as it maps
directly to an accessibility API intended for this purpose. Please provide
more information.

Received on Thursday, 17 June 2010 20:02:54 UTC