- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 21 Mar 2011 13:11:56 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: HTML WG <public-html@w3.org>, "W3C WAI Protocols & Formats" <w3c-wai-pf@w3.org>
hi henri, "In particular, the presence of ARIA attributes MUST NOT affect CSS pseudoclass matching" can you provide a code example that illustrates this? I am having problems wrapping my head around what you mean. thanks in advance stevef On 21 March 2011 03:51, Henri Sivonen <hsivonen@iki.fi> wrote: > 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/ > > > -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 21 March 2011 20:12:51 UTC