Re: Using ARIA to override semantics

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