Re: Using ARIA to override semantics

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