- From: Paul Cotton <Paul.Cotton@microsoft.com>
- Date: Wed, 10 Oct 2012 18:14:36 +0000
- To: Janina Sajka <janina@rednote.net>
- CC: W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, HTML WG <public-html@w3.org>, "Michael(tm) Smith" <mike@w3.org>, Michael Cooper <cooper@w3.org>, Jeff Jaffe <jeff@w3.org>, Tim Berners-Lee <timbl@w3.org>, Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, Philippe Le Hegaret <plh@w3.org>, Judy Brewer <jbrewer@w3.org>
We have recorded this formal objection to the WG decision on ISSUE-204 at: http://dev.w3.org/html5/status/formal-objection-status.html#ISSUE-204 Given the progress on subsequent changes to the material adopted for ISSUE-204, do you wish to maintain this Formal Objection? If so then we will keep it on this list so that it can be presented to the W3C Director at the next transition of the HTML5 specification. If not please let us know and we will drop it from the list. /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -----Original Message----- From: Janina Sajka [mailto:janina@rednote.net] Sent: Thursday, August 23, 2012 12:52 PM To: Tim Berners-Lee; Sam Ruby; Maciej Stachowiak; Paul Cotton; Philippe Le Hegaret; Judy Brewer Cc: W3C WAI Protocols & Formats; HTML Accessibility Task Force; HTML WG; Michael(tm) Smith; Michael Cooper; Jeff Jaffe Subject: Formal Objection on HTML Issue-204 Decision On 13 August 2012 the HTML Working Group formally decided to specify certain ARIA behavior in the HTML 5 specification. Because ARIA is a chartered deliverable of the PFWG and not of the HTML WG, because only PFWG is in a position to protect the overall integrity of the ARIA specification, because the HTML WG ignored protest from PFWG in reaching their decision, and because we believe the HTML WG intends imminently to rely on this decision for additional decisions potentially injurious to accessibility and to the ARIA specification, PFWG hereby formally objects to the HTML WG decision on both procedural and technical grounds and requests expedited handling of our objection by the W3C Director in order to minimize any additional damage to both Working Groups' specifications, timelines, and deliverables. The HTML WG decision in protest here is documented at: http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0111.html In reviewing the HTML WG Issue-204 decision, the PFWG ARIA Task Force concluded that the HTML WG decision "redefines how aria specification is defined." The ARIA Task Force discussion of this HTML-WG decision, including its request that PF file a Formal Objection is documented at: http://lists.w3.org/Archives/Public/wai-xtech/2012Aug/0003.html The PFWG's discussion and resolution is documented here: http://lists.w3.org/Archives/Public/wai-xtech/2012Aug/0002.html The HTML WG decision on Issue 204 determined to include the following statement specifically referencing ARIA markup behavior in Sec. 7.1 of its HTML 5 specification: "User Agents are encouraged to expose the full semantics of hidden elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby." Additional context and specifics of the HTML WG decision can be found in the change proposal which they adopted: http://www.w3.org/html/wg/wiki/ChangeProposals/AllowAriaReferHidden#Details PFWG notes that ARIA was not designed to convey semantic content for hidden descriptions. Rather, they expose these descriptions as text strings. These text strings are treated as text strings in the accessibility APIs on each OS platform and the assistive technologies on each OS Platform are not expected to process the text strings as though they were HTML content even when that content is NOT hidden (See aria-describedby in the table at: http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property). The alternative text computation algorithm for ARIA 1.0 is designed to output a flat string. That flat string is what User Agents are required to expose through Accessibility APIs (AAPIs) when they process ARIA 1.0 markup: See http://www.w3.org/WAI/PF/aria/roles#namecalculation. The HTML WG is asserting a fundamental redefinition of this essential ARIA behavior, which would cause multiple problems with assistive technology interoperability as indicated above, and has been explained in more detail in multiple locations including on the HTML WG Issue 204 survey. This redesign would also completely change a key aspect of interoperability between browsers and assistive technologies. Such a major change in the assistive technology field is unlikely to be feasible in the near term; and such a major change in ARIA-describedby behavior would also break ARIA describedby implementations in multiple already-deployed products. The HTML WG and its Co-Chairs were informed through multiple channels that the PFWG strongly opposes the HTML WG's attempted respecification of ARIA describedby, including most recently in the Issue-204 survey, where PFWG's ARIA Task Force Facilitator provided extensive technical objections to the proposed redefinition, and the PFWG's Chair noted that "If the HTML WG wishes to negotiate additional ARIA behavior for its HTML 5 specification, it should propose the particulars to the PFWG." https://www.w3.org/2002/09/wbs/40318/issue-204-objection-poll/results The PFWG notes that the HTML WG has successfully worked with PF in the past to achieve appropriate ARIA related specifications in HTML 5, most recently in the HTML WG's Issue-199: http://lists.w3.org/Archives/Public/public-html/2012Jul/0122.html Yet, in this instance, PFWG's objections were completely discounted in the HTML decision, which states: "... there were a number of objections that apply to both proposals, and in at least one case are made by the same individual against both proposals. If the people who felt this way had presented a third proposal, then these arguments would have been considered." The "people" referred to in this statement are the ARIA Task Force Facilitator, and the PFWG Chair. PFWG cannot accept a process which cedes decisions on ARIA behavior to the HTML WG by requiring PFWG to offer a suggested "third proposal" rather than talking with us directly. ARIA is a chartered deliverable of PFWG, not the HTML WG, and we strongly insist that other Working Group's specifications of ARIA behavior must be mutually agreed upon with PFWG, and not determined unilaterally by another Working Group. The PFWG therefore requests expedited handling of this formal objection to the above-cited HTML WG decision. We request that: 1.) HTML WG be directed to remove the above-cited sentence immediately. 2.) HTML WG be directed to work with PFWG to jointly agree on appropriate language for Sec. 7.1 of the HTML 5 specification, should the HTML-WG continue to desire a language change in that section that would specify ARIA behavior. PFWG notes again that ARIA is a PFWG chartered deliverable, and strongly protests another working group's unilateral attempt to define ARIA behavior. Because we believe HTML-WG intends to base additional decisions on its Issue-204 decision, we respectfully request our objection receive immediate expedited handling so that any damage to W3C specifications, timelines, and process may be kept minimal. Janina Sajka, PFWG Chair -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Wednesday, 10 October 2012 18:15:33 UTC