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

Dear Benjamin Hawkes-Lewis:



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 78: Relationship of ARIA to semantics (supporting comment)
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0055.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6. Implementation in Host Languages <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_lang_impl>
Status: Alternate action taken

-------------
Your comment:
-------------
 (with amendment at
<http://www.w3.org/mid/49E48F86.4030905@googlemail.com>)



This is a supporting statement and suggestion for the comment in
ISSUE-158



I strongly agree this [semantic markup] is a significant problem with the
sort of DOM ARIA is trying to make more accessible that is largely unsolved
by ARIA itself. It is hard to see how many of the examples in the draft
could be seen as conforming to WCAG 2.0 in principle or in detail.



I think the ARIA spec could do some things to mitigate the problem.



Either:



A. Demonstrate how one could reject all publisher styles and style an
ARIA-annotated DOM. This demonstration would take the form of an
informative guide, including CSS where possible. Compare:



http://dev.w3.org/html5/spec/Overview.html#rendering



This is not as ideal as a world in which publisher styles and user styles
can be mixed. It may be someone can come up with a clever way to deliver
that world too on top of ARIA, but the loss of publisher styles entire
would (I think) be an acceptable fallback position for ensuring
accessibility of content and functionality.



Or:



B1. Warn authors of this problem.



B2. Ensure all examples in the spec are be perceivable and operable when
rendered without CSS by providing explicit content. For example, "img"
elements with "alt" text could replace implied CSS background images.



It may be that the first approach is suitable for some ARIA features, and
the second approach for other ARIA features. It is unlikely both approaches
are suitable for a given feature, since user agent/user styles would
probably conflict with explicit content.

--------------------------------
Response from the Working Group:
--------------------------------
It is true that, ideally, ARIA would achieve its own syntactic
obsolescence. We expect that many features that now require ARIA will in
the future be natively supported by various host languages. However, for a
variety of reasons we expect that there will always be an ongoing need for
ARIA. We have added a discussion of this issue to the introduction at
http://www.w3.org/WAI/PF/aria/20091214/introduction#co-evolution. We have
also acknowledged host language evolution and introduced the concept of
"strong native semantics" in the section "Resolving Conflicts with Host
Languages" which you referenced. This allows for certain obsolescence of
ARIA over time.



To address your styling concern, many of the widgets found in HTML 5 do
not have corresponding platform system setting to represent their color
scheme. The CSS3 working group had created system properties that aligned
with system font and color settings on Windows. Those have been deprecated
as those settings are not provided consistently on different operating
systems or operating system versions. Furthermore, it is unlikely that many
mobile devices would have them at all. ARIA provides the flexibility for
the author to provide their own style sheet transformations that they may
not be able to deliver in the browser. For example, a user agent may not
have a high contrast color scheme for any widgets in their UI. This leaves
both the user and the author without a means to deliver these features.
Yet, an author could indeed provide these features in the markup bound to
CSS attribute selectors in ARIA. 



ARIA allows the author to deliver more flexibility to the user and author
but that flexibility depends on the user agent and operating system
platform's capabilities. It is therefore unrealistic to warn the author of
a problem which is entirely dependent on each and every browser platform
conceivable. 



The PF working group met with the CSS working group in the last Mandelieu
face to face. It was agreed that CSS attribute selectors, representative of
operating system properties, would be deprecated in CSS3. See the change in
the CSS3 specification:
http://www.w3.org/TR/2008/WD-css3-color-20080721/#css2-system

and this post to the CSS working group list that supports this decision
and conclusion.



We should note that Dojo does effectively respond to high contrast color
schemes.



The ARIA specification is about interoperability with assistive
technologies. We believe we have addressed your comment as it relates to
host level semantics and as it relates to styling. Due to the
inconsistencies in platform behavior, system color settings cannot be
guaranteed on each platform and therefore attempting to follow them in
either HTML 5 or CSS is unachievable. Therefore, we recommend that this be
addressed individually using WCAG 2 techniques.



We have added issues to our tracking system to coordinate with the Web
Content Accessibility Guidelines and User Agent Accessibility Guidelines
Working Groups on this.

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


Comment 296: Specify what ARIA information may be used by mainstream user agents to create UI
Date: 2009-09-03
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0010.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:
-------------
It's currently very unclear when ARIA may be used by mainstream user agents
to create UI.



Some evidence of confusion:



http://groups.google.com/group/free-aria/msg/1826be8e0919776c



http://lists.w3.org/Archives/Public/public-html/2009Sep/0120.html



http://lists.w3.org/Archives/Public/public-html/2009Sep/0144.html



http://lists.w3.org/Archives/Public/public-html/2009Sep/0157.html



http://lists.w3.org/Archives/Public/public-html/2009Sep/0212.html



There's a real tension between ARIA as a side-effect-free method for
divitis Ajax frameworks to support AT or bridge to HTML5, and ARIA as a
source of semantics for markup languages like SVG. I believe providing
normative language around this would clear up that tension.



Please specify in normative language in the WAI-ARIA specification what
ARIA information:



1. MUST only be exposed to APIs (DOM, CSSOM, accessibility APIs) for use
by assistive technology that harvests information via such APIs.

2. MAY/SHOULD/MUST be used by *any* user agent to provide UI (for example,
providing keyboard navigation through ARIA landmarks, or keyboard
operability of an ARIA checkbox).



If necessary, require host languages to define this for conformance.

--------------------------------
Response from the Working Group:
--------------------------------
We have added a section to the introduction that explains the difference
between mainstream user agent processing, and assistive technology
processing, at
http://www.w3.org/WAI/PF/aria/20091214/introduction#ua-support. It refers
to the WAI-ARIA User Agent Implementation Guide that provides normative
requirements for user agents processing. These requirements do not include
rendering requirements.

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