- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:33:54 +0000 (GMT)
- To: David Baron <dbaron@dbaron.org>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
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