Response to your comments on WAI-ARIA 1.0 Authoring Practices

Dear Sailesh Panchang:

Thank you for your comments on the 16 September 2010 Working Draft of
WAI-ARIA 1.0 Authoring Practices
(http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/). 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 8 March 2013 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=10;

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

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 with the
Director before the document is finalized as a Working Group Note, 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 348: Changing reading order
Date: 2010-10-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0003.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 4.3.  Changing the Reading Flow <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#relations_flowto>
Status: Alternate action taken

-------------
Your comment:
-------------
In the following example, the navigation would follow the order of "Top
News Stories", "television listings", "stock quotes", and "messages from
friends" by following (X)HTML document reading order. However, the author
or end user may determine that the main content is most important, followed
by "stock quotes", "messages from friends", and then "TV listings."

If the end user wishes to follow a different reading order, he cannot
change the code and add aria-flowto but has to review the headings /
landmarks and navigate to the desired section of the page. Proper
structural markup will support such navigation. 

Does above text suggests that end user is in control and can set
aria-flowto attribute?
 
And if the author intends that a different reading order is more
appropriate or logical, then why code it in a different order to begin
with?

Consider a newspaper. The headlines  that scream out the top news story /
breaking story are at the top center of the page for a reason, right? It
does not appear in the bottom right section.
In a top-down-right to left order system, the reading and tab order  should
follow this pattern.

If a sighted keyboard user experienced the tab going  to  the main content,
then the right side content then the footer content and then the left
content he would be perplexed. It is not predictable at all and can
different from website to website or even Web page to Web page. If landmark
based navigation is possible for a sighted user (like it is for a screen
reader user)  and some landmarks are skipped over, then that too will be
confusing.  

I think this is a poor example for a case where reading / tab order should
be different from coding order. 

Finally, aria-flowto is not supported by browsers and AT as of today.
I am not familiar with model based authoring  paradigm and cannot  comment
about the need to change reading flow.

--------------------------------
Response from the Working Group:
--------------------------------
A user could change the reading order of an a personalized portal by an
interface allowing a user to change the reading order for a screen reader.
It does not mean they need to code aria-flowto by hand. The UI could also
do things like save the footer for last if it wanted. The example is simply
used to show how flowto would be marked up to change the reading order. 

We have modified the text to state when the user could control the flow of
a page for clarity.

NVDA does support aria-flowto in its IAccessible2 implementation as part of
its IAccessible2 support. We are aware of work on aria-flowto support being
implemented designed into at least one other major screen reader now. This
will be required for candidate recommendation.

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


Comment 349: aria-labelledby
Date: 2010-10-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0004.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 4.1.1. Labeling <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#LabeledBy>
Status: Accepted proposal

-------------
Your comment:
-------------
Refer to  "It should be noted that (X)HTML provides a < label for> element
which you can use to label form controls. For all visual objects, including
(X)HTML form elements, you should use the WAI-ARIA  aria-labelledby
property for labeling."

The second statement above suggests that one “should” use the
aria-labelledby for (X)HTML form controls too instead of the ‘LABEL
for’? If the HTMl LABEL is sufficient and works with browsers and AT old
and new, why should one switch to aria-labelledby if there is a one to one
relationship?  

Maybe it should clarify that it is useful for html form elements when
multiple labels need to be associated because the labelledby attribute can
have multiple ids.

Example:

<table border="1">
<tr><th>Question</th><th id="yes">Yes</th><th id="no">No</th><th
id="dnk">Do not know</th></tr>
<tr><th id="q1">Are there enough bond fund choices in your 401k?</th>
<td><input type="radio" aria-labelledby="q1 yes" name="q1ans" />
<td><input type="radio" aria-labelledby="q1 no" name="q1ans" />
<td><input type="radio" aria-labelledby="q1 dnk" name="q1ans" />
</tr>
<tr><th id="q2">Are there enough index fund choices in your 401k?</th>
<td><input type="radio" aria-labelledby="q2 yes" name="q2ans" />
<td><input type="radio" aria-labelledby="q2 no" name="q2ans" />
<td><input type="radio" aria-labelledby="q2 dnk" name="q2ans" />
</tr>
</table>

--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment and have modified the section on Labeling.

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


Comment 350: landmark roles
Date: 2010-11-12
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0014.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.7.  Providing Navigable Structure within Web Pages <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_layout>
Status: Proposal not accepted

-------------
Your comment:
-------------
The makers of JAWS for Windows (Freedom Scientific) believe that it is
useful to categorize additional roles as landmark roles for the benefit of
AT users. Examples: article, region, directory, status, notes. I second
this. The JAWS Support For ARIA doc available under What's New in JAWS 12
lists these additional roles and FS states that JAWS supports these roles
as landmarks. 

--------------------------------
Response from the Working Group:
--------------------------------
We are satisfied with the set of roles considered landmarks and do not
believe a change to the taxonomy would be useful. However, WAI-ARIA does
not dictate how an assistive technology chooses to render WAI-ARIA in its
user interface, nor does it define authoring practices that are geared to a
specific assistive technology. We do, however, encourage assistive
technology vendors to share with industry how they render WAI-ARIA content
as Freedom Scientific has done with the JAWS Support for ARIA doc.

Received on Tuesday, 26 February 2013 14:58:07 UTC