Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Dear David Todd:



Thank you for your comments on the 24 February 2009 Last Call Working
Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2009/WD-wai-aria-20090224/). 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 1 February 2010 to say whether you accept them or to discuss additional
concerns you have with our response. 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=1;



* 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 Accessible Rich Internet
Applications (WAI-ARIA) 1.0 editors' draft at
http://www.w3.org/WAI/PF/aria/20091214/.



Due to the scope of changes made in response to comments on the Last Call
Working Draft of WAI-ARIA, we are returning the specification to Working
Draft status. We will shortly publish a public "stabilization draft" of
WAI-ARIA and updated Working Drafts of the accompanying documents. While
these versions will not incorporate further discussion based on your
acknowledgement of our response to your comments, we will work with you on
your feedback as part of our preparation for the following version. You are
also welcome to submit new comments on the new public versions in addition
to sending your acknowledgement of our response to your previous comments.



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 Accessible Rich Internet Applications
(WAI-ARIA) 1.0.



Regards,



Janina Sajka, PFWG Chair

Michael Cooper, PFWG Staff Contact


Comment 43: Global change: ARIA to WAI-ARIA
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Accepted proposal

-------------
Your comment:
-------------
Global change: ARIA to WAI-ARIA

--------------------------------
Response from the Working Group:
--------------------------------
We have agreed to change instances of "ARIA" to "WAI-ARIA".

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


Comment 44: Heading levels with labelledby and level
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - heading (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#heading>
Status: Answered question

-------------
Your comment:
-------------
Regarding the following statement: "Often, heading elements will be
referenced with the aria-labelledby attribute of the section for which they
serve as a heading. If headings are organized into a logical outline, the
aria-level attribute may be used to indicate the nesting level."  Will this
cause a screen reader to double speak a heading?

--------------------------------
Response from the Working Group:
--------------------------------
The W3C does not define how a screen reader presents its user interface.
However, it is not likely that an assistive technology will double speak a
header. If it is doing landmark navigation it should speak the region type
and its header. If it is doing header navigation it should skip the regions
and announce the headers.

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


Comment 45: Duplicate landmarks
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - main (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#main>
Status: Answered question

-------------
Your comment:
-------------
Regarding the following statement: "Note: Because document and application
elements can be nested in the DOM, they may have multiple main elements as
DOM descendants, assuming each of those is associated with different
document nodes, either by a DOM nesting (e.g., document within document) or
by use of the aria-owns attribute."  How AT deal with duplicate main
landmarks?

--------------------------------
Response from the Working Group:
--------------------------------
How an assistive technology processes duplicate marks is based on the
assistive technology, however use of the document hierarchy is very
valuable in providing structural navigation of landmarks. In the case of
JAWS, it lists landmarks based on the document hierarchy. So, if there is
more than one, the user can sequence through them as they appear in the
tree view. By placing them in the tree view, their context within the
document hierarchy is preserved. 



There may be instances where a portlet has its own structure which
includes a main content area separate from the overall portal page. Each
landmark is then associated with its label. 



To address your specific question which we believe has to do with multiple
main content landmarks on the same level, the user can sequence through
them provided all folders in the tree view are collapsed. There could in
fact be more than one main content section. 

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


Comment 46: Politeness level of marquee
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - marquee (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#marquee>
Status: Accepted proposal

-------------
Your comment:
-------------
Regarding the following text: "marquee (role)

A type of live region where non-essential information changes frequently.
Also see log.

Common usages of marquee include stock tickers and ad banners. An example
of a marquee is a stock ticker. The primary difference between a marquee
and a log is that logs usually have a meaningful sequence of more important
content changes."  What is the politeness level?

--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment and will add the text:



Note: Elements with the role marquee maintain the default aria-live value
of off.

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


Comment 47: Menu discuss separator and group
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - menu (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#menu>
Status: Alternate action taken

-------------
Your comment:
-------------
Regarding the menu role, should the separator and group roles be discussed
here as well? 

--------------------------------
Response from the Working Group:
--------------------------------
In the ARIA specification the description of the role appears sufficient to
itself. However, it makes sense to provide further guidance for authors
about how menus should be used with other roles, including separator,
menuitemradio, menuitemcheckbox. We will expand the menu design pattern in
the ARIA Best Practices accordingly. This change is not yet in place but we
expect it to be in place in the next public draft. This is our ACTION-462.

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


Comment 48: Double-speak caption
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - presentation (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#presentation>
Status: Answered question

-------------
Your comment:
-------------
For the following example:

<div role="img" aria-labelledby="caption">

  <img src="example.png" role="presentation" alt="">

  <p id="caption">A visible text caption labeling the image.</p>

</div>



Does a screen reader double speak "A visible text caption labeling the
image" - once for the image and again as the paragraph is navigated to? 

--------------------------------
Response from the Working Group:
--------------------------------
The W3C does not dictate how a specific screen reader should speak
something as it is part of their user interface. That said, the aria
implementers guide states that the text equivalent computation be such that
the aria-labelleby attribute take precedence over the alt text when
computing the accessible name for the object. If the assistive technology
interacts with the image through the accessibility API no double speaking
should occur. If, however the AT goes through the DOM, there is a
possibility that the scripted UI of the screen reader could cause double
speaking as the author has essentially provided the text equivalent twice.

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


Comment 49: Heading role
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - region (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#region>
Status: Accepted proposal

-------------
Your comment:
-------------
The region role says a region SHOULD have a heading provided an element
with a heading role.  Shouldn't the first choice be an HTML heading?

--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comments and will be making the following changes:



<change>

A region SHOULD have a heading, provided via an instance of the heading
role or by using the standard accessible name calculation.

</change>

<to>

A region SHOULD have a heading referenced by aria-labelledby. This heading
should be provided via an instance of the standard host language header
element or an instance of an element having the role of heading and
containing the heading text.

</to>

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


Comment 50: Spanning table headers
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - columnheader (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#columnheader>
Status: Alternate action taken

-------------
Your comment:
-------------
colheader/rowheader role - Some data tables cells span multiple rows or
columns and the table "headers" and "id" attributes are used to associate
cells with specific headings. Complex data tables require additional markup
to explicitly associate the heading with the data. In the data cells, the
headers attribute is used on the td element to specify which heading cell,
via the id attribute on the th element, is associated with a specific data
cell.  Does ARIA provide support for column and row headings that span
multiple columns and rows?  As I mentioned, HTML tables provide the id and
headers attributes.

--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA is not meant as a replacement for HTML tables. If the author
wishes to have headers that span multiple columns or rows this can be
achieved by overlaying ARIA on an HTML table or by using aria-labelledby to
have a cell reference its corresponding table. We have updated the grid
design pattern in the ARIA Best Practices Guide to reflect this.



For ARIA 2.0, we will reconsider the issue of spanning gridcells.

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


Comment 51: Clarify relevant
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-relevant (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-relevant>
Status: Proposal not accepted

-------------
Your comment:
-------------
Under the aria-relevant (property), it says "text is added or removed from
the DOM".  Should this sentence be deleted? How is adding or removing a DOM
text node different from other notes (mentioned directly above the sentence
about adding/removing text)? 

--------------------------------
Response from the Working Group:
--------------------------------
This sentence should not be deleted. The aria-relevant property specifies
what type of changes to listen for in the live region. The assistive
technology will want to attach listeners for specific events in a live
region. Imagine a name in a buddy list. You would want to listen for text
node changes to indicate whether the someone has entered or left a chat
room. The assistive technology would be interested in a <div> disappearing
in this scenario, it is only interested in the text. This would allow the
AT to ignore other changes to the live region.

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


Comment 52: Tree completely represented
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.5. Example: Building a Tree Widget <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Exampletree>
Status: Accepted proposal

-------------
Your comment:
-------------
Regarding the following statement: "If the tree is not completely
represented in the DOM at all times, don't use either the structured or
aria-owns methods. Instead use aria-level, aria-posinset and aria-setsize."
  How does one know if the tree is completely represented in the DOM at all
times? 

--------------------------------
Response from the Working Group:
--------------------------------
Thank you for your comment.



We have changed the text:

"If the tree is not completely represented in the DOM at all times, don't
use either the structured or aria-owns methods. Instead use aria-level,
aria-posinset and aria-setsize."



to:

"If items in the tree are loaded, for example, via the XMLHttpRequest
object and thus not present in the DOM at all times, don't use either the
structured method mentioned above, or the aria-owns method. Instead use
aria-level, aria-posinset and aria-setsize."



We hope that this clarifies the situation.

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


Comment 53: Structured method for tree
Date: 2009-04-08
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0036.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.5. Example: Building a Tree Widget <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Exampletree>
Status: Alternate action taken

-------------
Your comment:
-------------
Regarding the following statement: "If the tree is not completely
represented in the DOM at all times, don't use either the structured..." 
What is the structured method? Is this what was described above in the code
sample for a tree (directly above this text)? If so, refer back to that
code sample. 

--------------------------------
Response from the Working Group:
--------------------------------
We addressed this issue in our response to your previous comment, our
comment 52.

Received on Tuesday, 15 December 2009 00:34:11 UTC