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

Dear David Baron:



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 37: Over-broad scope of spec
Date: 2009-04-06
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0031.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 1.1. Scope <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#About>
Status: Accepted proposal

-------------
Your comment:
-------------
1.1. Scope says:

  # The goals of this specification include:

  #  * defining what information may be controlled by the author;

  #  * supporting device independence for new devices such as

  #    telephones, PDAs, and televisions;

  #  [...]

The first of these points seems extremely broad; it should probably

be scoped further.  Furthermore, it is unclear to me how the

specification addresses the second.

--------------------------------
Response from the Working Group:
--------------------------------
Thank you for your feedback. We agree the scope needs to be narrowed

slightly.



We shall make the following changes:



<change>

    * defining what information may be controlled by the author;

    * supporting device independence for new devices such as telephones,
PDAs, and televisions;

    * improving the accessibility of dynamic content generated by scripts;
and

    * providing for interoperability with assistive technology.

</change>

<to>

    * expanding the accessibility information that may be supplied by the
author;

    * requiring that supporting host languages provide full keyboard
support that may be implemented in a device independent way such as by
telephones, handheld devices, e-book readers, and televisions;

    * improving the accessibility of dynamic content generated by scripts;
and

    * providing for interoperability with assistive technology.

</to>

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


Comment 38: Relationship of ARIA to semantics
Date: 2009-04-06
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0031.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:
-------------
My biggest concern with section 6 (Implementation in Host Languages)

is somewhat broader rather than about particular pieces of text.  I

think the WAI-ARIA specification should encourage its own syntactic

obsolescence (which I distinguish from semantic obsolescence).  By

this, I mean that I think the syntax described in the specification

ought to be temporary, only until markup languages such as HTML

define vocabularies that can be mapped into the breadth of the

semantics in the WAI-ARIA specification (and are mapped that way by

default).



Having semantic markup for these things that is not specific to

assistive technology will lead to benefits for users, including

accessibility benefits.  For example, in Firefox, users who have

configured a Windows high contrast theme get by default the Firefox

preference to ignore colors specified by the author.  This

preference causes problems with some types of markup where authors

construct their own controls -- the same types of markup that ARIA

is trying to make more accessible.  For example, with this

preference set, users are unable to see the selection in a tree

control, since that selection is expressed as an author-specified

color.  The ARIA annotations don't help here, but if the tree

control were marked up as an HTML5 tree control, there would be an

appropriate default color for the selected row.



More generally, semantic markup tends to be more accurate when it

causes more effects.  (This is the problem of hidden metadata

tending to become inaccurate.)  ARIA is somewhat self-limiting

because the markup is "hidden" to anybody not using assistive

technology.  However, in many cases, the markup would be useful to

others if it were not limited; thus I think the specification should

encourage host languages to obsolete the ARIA specification by

having semantic markup that, by default, covers the semantic range

covered by the ARIA markup (but applies to more than just assistive

technology).  It might help encourage this if the specification

explicitly encouraged host languages to define mappings from their

markup semantics to default values for ARIA semantics.



This makes me wonder whether section 6.1.4, which says, in full:

  # If the host language incorporates ARIA support and there is a

  # conflict between a host language feature and an ARIA feature,

  # assistive technology should assign preference to the ARIA

  # feature.

is really the right way to go.  However, I suppose it's a

SHOULD-level requirement, so that if the Web evolves such that

assistive technology implementers find they get a better user

experience from making the opposite choice, they ought to.  However,

I wonder whether the specification should really even have a

SHOULD-level requirement for what ought to be governed by trying to

give users the best experience.  (However, I concede that having

this SHOULD may behavior more predictable to authors.)

--------------------------------
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 obsolescence of certain
ARIA features over time.

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


Comment 39: Focus navigation
Date: 2009-04-06
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0031.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.3. Focus Navigation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_focus>
Status: Alternate action taken

-------------
Your comment:
-------------
I'm also a bit puzzled by section 6.1.3 (Focus Navigation).  It

seems like it might be in the spec not because it fits with the rest

of the spec, but because it's something that the spec's authors

would like to enforce on other languages.  That said, I think it

doesn't make sense, because it doesn't necessarily make sense for

*any* element to be focusable (consider elements inside the head

element in HTML), and because languages might want to limit

extensibility to certain elements rather than allowing all elements

to be used to build controls like those ARIA is intended to provide

information about.

--------------------------------
Response from the Working Group:
--------------------------------
We understand your concern and addressing this

has resulted in extensive deliberation. The challenge we have is WAI-ARIA

is a cross-cutting technology. We cannot limit focus to any

language-specific elements. For example, Adobe Flex would benefit from
the

use of WAI-ARIA as has XUL. What we absolutely cannot afford is to allow

what happened with HTML. We allowed the host language provider to
determine

what should be focusable and consequently were left with an enormous

keyboard accessibility problem for over a decade. The result has been a

very unusable keyboard interface for all users who were restricted by

having to use links and form elements to be keyboard accessible. We knew

there would be a comment on this requirement, however the reality is
making

this requirement hurts nothing. No author will try to give an element

within the head element focusable.



We had originally had tabindex changes included in WAI-ARIA to support

accessibility but agreed that due to having to support multiple host

languages we left it up to the host language and because tabindex changes

needed are now implemented in HTML 5 and in all mainstream HTML browsers

today.

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