Response to your comments on WAI-ARIA 1.0 Authoring Practices

Dear Janina Sajka:

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 366: aria-describedby targeting hidden elements
Date: 2012-03-04
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2012JanMar/0012.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 4.1.2.3. Descriptions on external pages <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#Descriptions_external>
Status: Accepted proposal

-------------
Your comment:
-------------
This comment was forwarded to the comments list by Janina Sajka to trigger
PFWG processing of a set of issues related to HTML implementation of ARIA.

http://www.w3.org/WAI/PF/aria-practices/#Descriptions_external

Quote: "if you wish to reference an external resource with 
aria-describedby, you can reference a link that in turn references the 
external resource"

And then it offers this this example, which I simplify for brevity:

   <img src=histogram
       alt="Histogram of Blackberry tree heights"
       aria-describedby=longdesc >
   <a id=longdesc href=link target=_description>Histogram data</a>

Comment: I have earlier proposed to change this text - even to remove  it -
because it did not speak to the facts. But now, I have heard from  Jonas,
that this technique already works, for visible elements. [Though  when I
asked, he did not point me to a particular build of Firefox for  testing.]
What ISSUE-204 promises is that what the ARIA Practises  document here
describe for a link without HTML5's @hidden attribute,  would also be
possible for a link with HTML5's @hidden attribute.

BUT NOTE: The link inside this example could very well be hidden,  despite
the fact that does not have aria-hidden=true. For instance: It  might have
been placed off-screen via CSS. The example does not say  anything about
this. [But note that ARIA 1.0 says that when an element  is hidden, then it
should have aria-hidden=true. So it is quite  possible that this element
should have had that. Because, as long as it  is not hidden, it would be
read read twice by the AT: Once when  presenting the aria-describedby
relationship and once when the  rendering proceeds to the next
element,after the <img>.] 

--------------------------------
Response from the Working Group:
--------------------------------
We have added text as suggested.

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


Comment 367: tooltip could have long description
Date: 2012-03-04
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2012JanMar/0012.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 4.1.2.2. Using a tooltip as a description <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#Descriptions_tooltip>
Status: Proposal not accepted

-------------
Your comment:
-------------
This comment was forwarded to the comments list by Janina Sajka to trigger
PFWG processing of a set of issues related to HTML implementation of ARIA.

http://www.w3.org/WAI/PF/aria-practices/#Descriptions_tooltip

Hm. I guess a role=tooltip element could contain a link to a long 
description ... 

--------------------------------
Response from the Working Group:
--------------------------------
While it is possible for a tooltip to reference a long description, in
general this is a design pattern that would not be useful and therefore we
are not including it in the document.

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


Comment 368: longdesc does not require external description
Date: 2012-03-04
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2012JanMar/0012.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.7.5.2.  Marking Descriptive Sections <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_layout_remaining_description>
Status: Accepted proposal

-------------
Your comment:
-------------
This comment was forwarded to the comments list by Janina Sajka to trigger
PFWG processing of a set of issues related to HTML implementation of ARIA.

http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description

Quote: "This is unlike longdesc which typically requires the author to 
create a separate file to describe a picture." 

Comment: Longdesc does not 'typically require this' - it is just that 
longdesc typically is *used* that way. 

--------------------------------
Response from the Working Group:
--------------------------------
We have modified the text to clarify your concern.

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


Comment 369: Why should descriptions be show to all?
Date: 2012-03-04
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2012JanMar/0012.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.7.5.2.  Marking Descriptive Sections <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_layout_remaining_description>
Status: Accepted proposal

-------------
Your comment:
-------------
This comment was forwarded to the comments list by Janina Sajka to trigger
PFWG processing of a set of issues related to HTML implementation of ARIA.

http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description

Quote: "It is preferable to have the descriptive text in prose as well  so
that it is readily available to all users"

Comment: Question: Why is it preferable, when this could lead to 
repetition? At any rate: That it is preferable, means that the text  take
account for the fact that some will hide the description. 

--------------------------------
Response from the Working Group:
--------------------------------
We like aria-describedby for visible descriptions as web developers did not
like having to create another page for the description and because
cognitively impaired users could often get confused when having to switch
context to go to another page to get the description.

Hidden text is not readily available to all users. It is not available to
visual users. Hidden text was only supported because Freedom Scientifc was
directing developers to supply special JAWS attributes to provide help text
that could be applied to individual form elements. We allowed for hidden
content to be used for accessible descriptions to aid blind users and
standardize the feature.

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


Comment 370: aria-describedby vs longdesc
Date: 2012-03-04
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2012JanMar/0012.html
Relates to: WAI-ARIA 1.0 Authoring Practices - 3.2.7.5.2.  Marking Descriptive Sections <http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#kbd_layout_remaining_description>
Status: Answered question

-------------
Your comment:
-------------
This comment was forwarded to the comments list by Janina Sajka to trigger
PFWG processing of a set of issues related to HTML implementation of ARIA.

http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description

Quote: "This is the preferred vehicle for providing long descriptions  for
elements in your document. … snip … aria-describedby can also be  used
to point to a link to another page"

Comment: The sections discusses @longdesc many times. But says that 
@aria-describedby is the preferred method for long descriptions inside  the
document. And, despite that it claims that @longdesc's primary role  is to
point to other documents, it does demonstrate how to do the same  with
@aria-describedby. 

This document several times demonstrates how to use the alt attribute 
correctly. BUT NOT A SINGLE TIME DOES IT DEMONSTRATE HOW TO USE  @longdesc
- not even when it speaks about pointing to external  documents.

The elephant in the room .... No! The elephants - in plural. If the  ARIA
Task Force has reached a 'different conclusion' about - hm -  @longdesc,
then it has done its best to hide it. 

--------------------------------
Response from the Working Group:
--------------------------------
We originally defined aria-describedby with the assumption that off-page
content was handled elsewhere. At the time that was longdesc and has not
yet been replaced by another feature. ARIA itself is agnostic to how the
use case is met, but it is important to understand that this use case does
not conflict with or replace the use case met by aria-describedby, but
rather complements it. 

With respect to alt and longdesc, it is not the responsibility of the ARIA
Authoring Practices Guide to document how to use the accessibility features
of HTML. So, if we did not document fully either ALT or longdesc that is
acceptable. Perhaps an Authoring Practices Guide should be created for HTML
5.

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