- From: Michael Cooper <cooper@w3.org>
- Date: Thu, 02 Dec 2010 22:26:46 +0000
- To: Todd Kloots <kloots@yahoo-inc.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Todd Kloots: Thank you for your comments on the 16 September 2010 Last Call Working Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0 (http://www.w3.org/TR/2010/WD-wai-aria-20100916/). 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 9 December 2010 to say whether you accept them or to discuss additional concerns you have with our response. If we do not hear from you by that date, we will mark your comment as "no response" and close it. If you need more time to consider your acknowledgement, please let us know. 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=9; * 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/20101202/. 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 340: Exceptions to host language precedence Date: 2010-10-28 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0012.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2. Using WAI-ARIA <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#usage> Status: Alternate action taken ------------- Your comment: ------------- The spec states that host language states and properties take precedence over ARIA states and properties to avoid a conflict. This might have exceptions. For example, in the case of creating a DHTML autocomplete developers need to set the "autocomplete" attribute on a textbox to "off" in order to suppress the default browser autocompletion, but set the "aria-autocomplete" attribute to the appropriate value. For example: <input type="text" aria-label="Tag" role="combobox" aria-expanded="true" autocomplete="off" aria-autocomplete="list" aria-owns="owned_listbox" aria-activedescendant="selected_option"> <input type="text" aria-label="Tag" role="combobox" aria-expanded="true" aria-autocomplete="list" aria-owns="owned_listbox" aria-activedescendant="selected_option"> <ul role="listbox" id="owned_listbox"> <li role="option">Zebra</li> <li role="option" id="selected_option">Zoom</li> </ul> If browsers or AT manufacturers follow the spec as currently written, the host language attribute of "autocomplete" would win out over the "aria-autocomplete" and AT wouldn't announce that the control has autocomplete. -------------------------------- Response from the Working Group: -------------------------------- The WAI-ARIA specification section 7.5 http://www.w3.org/TR/2010/WD-wai-aria-20100916/host_languages#host_general_conflict defines that ARIA overrides host language semantics by default, unless the host language defines more precisely how ARIA and the host language interact. HTML 5 is defining this via the HTML to Platform Accessibility APIs Implementation Guide. A unofficial in-progress draft of this document is available at http://dev.w3.org/html5/html-api-map/overview.html. Regarding this specific case, the HTML 5 accessibility API mapping simply needs to state how user agent conveys the autocomplete information to off and handle the error case for when the author applies an aria-autocomplete to that element. That effort should also address API mapping issue when native host language support overrides ARIA markup. Only the host language can define the response to the error conditions as it depends on the host language. The HTML 5 specification defines where WAI-ARIA is allowed and where it is not to avoid host language conflicts. To make sure your specific concern is addressed in the above documents, we have created an action with the HTML accessibility task force, which is working on ARIA to HTML mapping. This is their action 89 http://www.w3.org/WAI/PF/HTML/track/actions/89. ---------------------------------------------------------------------- Comment 341: Extra markup on menuitems Date: 2010-10-28 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0012.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7.4. Text Alternative Computation Example #1 <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#tac_example1> Status: Accepted proposal ------------- Your comment: ------------- The example shows use of basic menutiems with the aria-haspopup property set to "false". For example: <ul role="menubar"> <!-- Rule 2A: "File" label via aria-labelledby --> <li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span> <ul role="menu"> <!-- Rule 2C: "New" label via Namefrom:contents --> <li role="menuitem" aria-haspopup="false">New</li> <li role="menuitem" aria-haspopup="false">Open</li> </ul> </li> </ul> Is this now the recommended approach? If so, it seems like a waste of bytes. All previous ARIA menuitem markup examples I have seen show that menuitems without a submenu just have a role of "menuitem" and that's it. I think that the "aria-haspopup='false'" should be implied if it is simply left off. -------------------------------- Response from the Working Group: -------------------------------- Although this is perfectly valid given that aria-haspopup is a boolean we agree that it is not necessary to indicate that a menuitem has an aria-haspopup value of false. We have removed the property from the elements, in the example, that do not support a sub menu. ---------------------------------------------------------------------- Comment 342: Toolbar should be composite Date: 2010-10-28 Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0012.html Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.3.2. Widget Roles <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#widget_roles> Status: Alternate action taken ------------- Your comment: ------------- Section 5.3.2 lists the roles that act as composite containers. However, the role of "toolbar" isn't on this list, but rather is listed in the "Document Structure" roles list in section 5.3.3. This seems like a mistake. A toolbar is a composite considering that, like all other composite controls, it has a set of decendant controls (buttons) whose focusability needs to be managed by the container. This is further reinforced later in the spec in the role definition for toolbar, where it states that "To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus." -------------------------------- Response from the Working Group: -------------------------------- Toolbar used to be listed as a composite role. The taxonomy changed b/c toolbars can contain more than just buttons. For example, the following composite widgets are often contained within a toolbar: popup button sub-menus, single-select radio groups, and search comboboxes. We will add an example to the Authoring Practices document showing a toolbar containing another managed-focus widget, such as a radiogroup. The text in the toolbar role definition related to managing focus has been softened to a "MAY" statement.
Received on Thursday, 2 December 2010 22:26:53 UTC