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

Dear James Graham:



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 201: Comment on WAI-ARIA Role
Date: 2009-04-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0079.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - article (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#article>
Status: Accepted proposal

-------------
Your comment:
-------------
"Assistive technology must treat an article like a document in that article
must be processed like an application."



This sentence makes no sense to me. Is it just missing a (grammatical)
article? Also, it sounds like it is trying to specify a conformance
criterion on AT. Is this the case? If so it seems like the convention in
the rest of the document is to use MUST in these cases. (If not I don't
understand the point of the sentence)

--------------------------------
Response from the Working Group:
--------------------------------
We agree this is unclear. We are making the following change:



<change>

Assistive technology must treat an article like a document in that article
must be processed like an application. Unlike a document, the use of
articles allows the user to identify and follow related articles based on
the nesting.

</change>

<to>

When a user navigates an element assigned the role of article, assistive
technology that typically intercepts standards keyboard events MUST switch
to document browsing mode, as opposed to passing keyboard events through to
the web application. Assistive technologies MAY provide a feature allowing
the user to navigate the hierarchy of any nested articles.

</to>

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


Comment 202: Use of RFC 2119 Keywords
Date: 2009-04-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0080.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:
-------------
The ARIA draft uses RFC2119 keywords both in all uppercase ("MUST") and in
all lowercase ("must"). It is unclear if there is intended to be a
difference between these two. In general it would be extremely helpful in
understanding the draft if all RFC2119 keywords were avoided except where
they are being used in their RFC2119 sense since doing so makes it very
easy to determine what is a conformance criteria and what is not.

--------------------------------
Response from the Working Group:
--------------------------------
We agree that it is confusing to have normative looking statements in
informative text. We are developing rewording to avoid the confusion and
clarify the intent behind such statements, or converting them into
normative RFC 2119 statements where appropriate. We are also clarifying how
such words should be interpreted in the "Normative Requirements for
WAI-ARIA" section.

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


Comment 278: Requirements for role=presentation
Date: 2009-08-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0001.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: Accepted proposal

-------------
Your comment:
-------------
The ARIA draft currently says:



"The user agent MAY choose not to present all structural aspects of the 

element being repurposed. For example, for a table marked as 

presentation, the user agent would remove the table, td, th, tr, etc. 

elements from the accessibility API mapping, while preserving the 

individual text elements within them. Because the user agent knows to 

ignore the structural aspects implied in a table, no harm is done by 

using a table for layout."



This "MAY" level requirement is too weak to ensure interoperable 

behaviour of UAs and too weak to allow authors to code against. Despite 

the example there is no assurance that a conforming UA would indeed 

propagate this role information to the children of the table so a 

careful author would have to write



<table role=presentation>

<tr role=presentation>

<td role=presentation>

[...]



Other cases are also unclear; for example it is unclear if the alt text 

in <img role=presentation alt="Holiday photo"> should be read out by a 

conforming UA.



The ARIA spec should tighten up these cases, possibly by explicitly 

deferring to the host language (rather than the user agent) to define 

where the role value is inherited.



--------------------------------
Response from the Working Group:
--------------------------------
We agree. The ARIA specification has tightened up the requirements for the
presentation role.

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