- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 21 Mar 2011 12:51:16 +0200
- To: HTML WG <public-html@w3.org>
- Cc: W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
On Sun, 2011-03-20 at 06:28 -0400, Sam Ruby wrote: > On 03/20/2011 04:49 AM, Henri Sivonen wrote: > > On Sat, 2011-03-19 at 11:50 -0500, Richard Schwerdtfeger wrote: > >> For ARIA 1.0 and HTML 4.x all ARIA roles can override anything. > > > >> Section 3.2.6 states what roles are allowed to overrided the default > >> host language semantics. > > > > Previously, the story was that ARIA can only override semantics as far > > as the accessibility API mapping was concerned and wasn't supposed to > > affect any other semantic-sensitive processing. Does that story still > > hold? > > I encourage you to identify the section of text in the draft spec and/or > the delta that Stephen supplied that you find to be unclear? My question wasn't about Steve's drafts/CPs/deltas. My question related to what Rich said. > It would be best for all concerned if conformance and interoperability > three years from now were defined by what the spec actually says and > what the tests actually cover and not be based on what somebody thought > somebody else meant when they made a post to a mailing list three years ago. I agree. However, knowing what the spec authors are trying to say would make it easier to propose text that actually says what's intended or to argue that the spec authors are intending the wrong thing. At present, the ARIA family of specs seems internally confused. http://www.w3.org/WAI/PF/aria/host_languages#host_general_conflict says "In addition to these normal situations in which WAI-ARIA is expected to override native semantics--" without having any qualifications or limitations scoping the semantic override only to what's exposed to assistive technologies. However, http://www.w3.org/WAI/PF/aria/conformance#ua_noninterference says "WAI-ARIA processing by the user agent MUST NOT interfere with the normal operation of the built-in features of the host language." but doesn't define what constitutes "normal operation". AFAICT, http://www.w3.org/WAI/PF/aria-implementation/ covers exposing things to accessibility APIs but doesn't explicitly say that implementors shouldn't do anything else with ARIA. To give another example that demonstrates that the ARIA family of specs in internally confused: http://www.w3.org/WAI/PF/aria/conformance#ua_domchanges says "When a web application maintains a local representation of accessibility information through WAI-ARIA roles, states, and properties, the user agent MUST provide a method to notify the web application when a change occurs to any of the related states or properties in the system accessibility API." which is directly contradicted by http://www.w3.org/WAI/PF/aria-implementation/#mapping_general "With respect to WAI-ARIA 1.0, accessibility APIs operate in one direction only. User agents publish WAI-ARIA information (roles, states, and properties) via an accessibility API, and an AT can acquire that information using the same API. However, the other direction is not supported." The continues to correctly observe "WAI-ARIA 1.0 does not define mechanisms for assistive technologies to directly modify WAI-ARIA information." With this background, one might guess that ARIA should have no observable effect beyond what's described in http://www.w3.org/WAI/PF/aria-implementation/ . Yet, http://www.w3.org/WAI/PF/aria/host_languages#host_general_conflict can easily be read to suggest otherwise. > Even better, can you propose specific text which would clarify the > situation? Sure: - - The presence of ARIA attributes in a document SHOULD NOT have observable effects in user agents compared to the absence of the attributes beyond what is exposed to assistive technologies and the effects that generally arise from having any attributes present in the DOM (the attributes being available via getAttribute, etc., and attribute selectors matching on the attributes' presence in the DOM). In particular, the presence of ARIA attributes MUST NOT affect CSS pseudoclass matching and SHOULD NOT affect user interface modalities that don't use assistive technologies. - - If the above paragraph is something that the PFWG does not mean, I think discussing what *is* meant by the PFWG definitely needs further discussion. To consider the case Jonas mentioned: If the ARIA role could be used to affect the context menu of elements, chances are that anti-context menu Web authors would harm accessibility by specifying a bogus role on the <a>, <img> and <video> elements to suppress context menu entries that let the user save files locally. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 21 March 2011 10:53:03 UTC