Re: Using ARIA to override semantics

Hi Richard,

I'm not intending to manufacture anything. Just trying to understand
how ARIA is intended to work in general, and especially in the face of
ARIA and native element providing conflicting semantics.

Though you don't answer it directly, based on the list in your email
it seems like you are saying that the answer to my central question
"Is it expected that we rewrite all such code to instead look at the
roles?" is "no". Is this correct? In other words, for non-AT users we
are not expected to use the semantics that ARIA roles provides, but
rather just the semantics that the HTML elements themselves provide.
While for AT users exposing the semantics defined by ARIA roles in
addition to (and with a higher priority than) the semantics
originating from HTML elements.

Am I correct in my understanding of your email?

*If* that is the case, is this specified somewhere in the ARIA
specification? And is this a MUST, SHOULD or MAY requirement? I.e. is
it encourage, discouraged, or not allowed for a HTML implementation
not targeted at AT users to use ARIA role semantics?

/ Jonas

> Jonas,
>
> You seem to be manufacturing some things that do not exist. The ARIA
> Implementation guide states how ARIA is used to support platform
> accessibility APIs. It does not specify any of the concerns that you raise.
>
> 1. I have never seen an API getElementsByRole nor have I seen such a
> proposal. We should not deprecate getElementByTagName. ARIA should not be
> needed if tags are used without modification due to the use of JavaScript
> and CSS. In a model view controller architecture, as applied to a node, the
> author changes the functionality of the element by modifying the controller.
> This happens whether you use ARIA or not.
>
> 2. ARIA is not meant to change a tag name. A fundamental concept you appear
> to be overlooking is that the author has used JavaScript to repurpose
> existing HTML elements. ARIA simply conveys the accessibility semantics
> intended by the author that are conveyed to an assistive technology. This is
> clearly defined in the ARIA User Agent Implementation Guide. It Does not
> provide any directive to the user agent as to how it should process HTML at
> ALL. Rather, the author used JavaScript to enhance the functionality of the
> page which is allowed as script is allowed on the page.
> 3. ARIA overrides the host language semantics defined by the tags conveyed
> to assistive technologies to convey the authors intent.
> 4. ARIA does not impact HTML conformance checkers other than ARIA can only
> applied to HTML elements were it is allowed. The chairs reached consensus on
> this.
> 5. Accessibility test tools will test for the validity of how ARIA is
> applied based on the ARIA specification and the HTML elements it is allowed
> on per the HTML 5 spec.
>
>
>
>> If the answer is "yes, you should look at roles rather than names",
>> has this been discussed with HTML implementors (browsers, conformance
>> checkers and otherwise), and/or script authors? It seems like a pretty
>> fundamental change to the way HTML, and markup languages in general,
>> works, and so I would think buy-in from the various stake holders
>> would be beneficial.
>>
>> / Jonas
>>
>

Received on Saturday, 19 March 2011 01:52:39 UTC