Response to your comments on WAI-ARIA 1.0 User Agent Implementation Guide

Dear Sofia Celic-Li:

Thank you for your comments on the 15 December 2009 Working Draft of
WAI-ARIA 1.0 User Agent Implementation Guide
(http://www.w3.org/TR/2009/WD-wai-aria-implementation-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 4 August 2010, if possible to accommodate a short publication timeline
we have, 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=8;

* 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 User Agent
Implementation Guide editors' draft at
http://www.w3.org/WAI/PF/aria-implementation//.

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 User Agent Implementation
Guide. 

Regards,

Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact


Comment 327: Comment for UA implementation guide section 4.6.1.1 Text Alternative Computation
Date: 2010-06-15
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010AprJun/0000.html
Relates to: WAI-ARIA 1.0 User Agent Implementation Guide - 4.6.1.1. Text Alternative Computation <http://www.w3.org/TR/2009/WD-wai-aria-implementation-20091215/#mapping_additional_nd_te>
Status: Accepted proposal

-------------
Your comment:
-------------
One of the areas that I have not been able to find a sufficient
implementation solution for is labeling of form controls that need to
reference external text as well as themselves via the aria-labelledby
attribute. That is, the aria-labelledby attribute requires a list of values
that reference text external to the form control as well as the form
control's own title or aria-label attribute value.

While the aria-labelledby attribute is supported in later versions of
screen readers such as JAWS, it only works with references to external
labels and currently only if the form control does not have a title
attribute (or, presumably, an aria-label attribute when this is supported).
Attempting to reference the form control's title or aria-label attribute
value (via referencing the form control's ID value) is not supported. It
would seem that the current hierarchy imposed by the computation rules
would not allow such a concatenation of labels.

This means that I am back to using hacks that were used pre-ARIA. I am
required to either place all of the information in the title attribute
value (repeating text that is already present in the page) or I include a
hidden version of the form control's original title value (by hiding it off
screen). Neither of these should be necessary and ARIA has then failed to
improve this implementation issue. Also note that in this scenario a change
in design for the general audience is not desirable.

--------------------------------
Response from the Working Group:
--------------------------------
We have accepted your proposal.

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


Comment 328: live region option for announcing an update has occurred but not the change
Date: 2010-06-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010AprJun/0006.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-atomic (property) <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#aria-atomic>
Status: Proposal not accepted

-------------
Your comment:
-------------
I have an early recollection of an ARIA feature that does not seem to be
part of the specification now. I may have had this wrong from the start but
it is a feature that I would find very useful and I am not able to find
anything in the current specification to address it.

I would like to have a screen reader user notified that a particular live
region has been updated but not announce the change itself. 

To use an example implementation: I have a search page that includes a
search form at the top of the main content area and the search results
(table format) below the search form. As the user types characters into the
search edit field the search result table is updated. I would like to let
the user know that the search results have been updated but I do not think
that announcing the content of the search table is appropriate for each
character the user types.

This will allow the user to investigate the change at a time of their
choosing.

I have not been able to find an appropriate combination of ARIA properties
that would result in a screen reader announcing "Search results updated"
(with "Search Results" being the label for the live region) only.

--------------------------------
Response from the Working Group:
--------------------------------
This is a common use case for Ajax applications. The correct solution is to
mark a relationship between the search landmark and the search results by a
controls relationship. This allows the assistive technology to indicate to
the user that any action on a search will result in a change to another
part of the page. The user can then simply follow the relationship with
their assistive technology. The ability to identify and follow the controls
relationship is just now being implemented in screen readers. Beyond this
the author should not be specifying to the assistive technology how the
live region is to be rendered and when. The author should only provide
guidance and this would be done by marking the live region as being
"polite." The assistive technology should assess, based on what is
controlling it whether to speak a polite area or notify the user that the
area has changed.

Instead of providing the full search result as polite region, it's
sometimes more appropriate to only announce meta information of the search
results. This has to be provided by the author. This can be done by live
region messages, e.g. log. Use cases can be the amount of search results or
search suggestions available while typing. The amount of changes probably
are too much to consume and a reasonable meta information provided by the
author can be better. Example can be search suggestions while typing.

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


Comment 329: live region label announcement
Date: 2010-06-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010AprJun/0007.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.5.2. Live Region Attributes <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#attrs_liveregions>
Status: Alternate action taken

-------------
Your comment:
-------------
The current ARIA specification does not seem to allow for controlling
assistive technology announcement of a live region's label when updates are
announced.

In some situations it may be appropriate or necessary to indicate what is
being updated (search results, list of recommendations, etc) before
announcing the update. In other situations it may be perfectly adequate to
announce the update alone.

I have not found a property to control this within the current
specification so my proposal is to add a new one.

--------------------------------
Response from the Working Group:
--------------------------------
The speaking of labels for ARIA live regions is currently up to the
assistive technology. Author may choose to supply a label for the live
region based on whether they believe the live region label should be
spoken. However, the user interface for speaking live regions is still up
to the assistive technology. Given that assistive technology support for
live regions is still in the early stages as is their ARIA enablement on
the Web, we believe the expansion of live region support is an ARIA 2.0
issue as we need to see more assistive technology and user implementation
before expanding its scope. We have an issue ISSUE-161
<http://www.w3.org/WAI/PF/Group/track/issues/161> to address expansion of
live region support in ARIA 2.0 and have added a point in this issue to
evaluate further enhancement for labeling of live regions.

Received on Monday, 2 August 2010 21:45:55 UTC