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

Dear working group,

I attempted to respond via the W3C online account but it only presented
Comment 327 for a response and seemed to be unable to process the submission
of my acknowledgment. Here is an email response instead.

Thank you for taking my comments into consideration. Here are my responses.

Comment #327:
Response accepted.

Comment #328:
Response not accepted.

Please clarify the following statement " 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."

How is an assistive technology to make such a determination? Are you
suggesting that the type of element would determine the appropriate response
(such as, an edit box would announce the polite area change whereas a radio
button would simply notify a changed status)? I imagine that it would be
difficult, if not impossible, for software to make the appropriate
judgments. An appropriate announcement would be highly dependent on the
content being presented.

In regard to "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 may require adding content to the page that may not have been
originally present - such as "450 matches found" (the value is updated with
each character added by the user in the edit field). Is this what you
intended to convey?


Comment #329
Response accepted.
I think this will potentially suffer the same software limitations outlined
in Comment #328. I look forward to seeing the development.



Thank you, once again, for considering my comments.

Sofia Celic-Li



On Mon, Aug 2, 2010 at 2:45 PM, Michael Cooper <cooper@w3.org> wrote:

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