Re: aria mappings

<meta name="Doh!" value="I accidentally replied to Jim directly  
because I didn't realise this list prioritises the sender address  
over the list address in replies, so now I'm posting this to the  
list, although I've had some more thoughts about the matter (having  
reviewed the current draft of the spec) which I'll contribute  
tomorrow." />

On 23 Sep 2009, at 01:02:05, Jim Jewett wrote:

> Aria mappings have been tricky enough that I'm sending it here for
> review instead of just posting a bug.

Given that these controls are expected to be implemented as native
controls, there surely isn't any requirement to expose an ARIA role
property. ARIA roles are to be used when an element is being employed
for a purpose which is not described by its native semantics. So, for
example, if an img element is coerced through scripting into playing
the role of a checkbox, it is appropriate for it to expose the ARIA
role "checkbox" as a property; but a browser's native checkbox
implementation shouldn't do so, as its semantics are already
determined by its nature.

See WAI-ARIA section 2.4 [1], particularly step 2 where it is stated:
"Set roles to make sure elements behave predictably and correctly
describe the behavior of each element within the application, *unless
element behaviors are fully described by the native markup language*."
(my emphasis).

The purpose of ARIA roles is to allow user agents to determine that an
element has been given additional semantics by an author, so that it
may expose those semantics via the appropriate accessibility API. In
the case of native controls, additional semantics are not being added
by the author, but are inherent in the nature of the control. Although
it is still necessary for implementers to determine the optimal way to
expose those semantics to the platform accessibility API, it makes no
sense to expose ARIA properties; they are redundant in such a case.

To return to the checkbox example: setting an ARIA role of "checkbox"
on the img element allows a user agent to expose it to the platform
API _as if it were_ a native checkbox element. Clearly there is no
need for such a property on a native checkbox - the user agent already
knows to expose it as a checkbox.

[1] <>


Nick Fitzsimons

Received on Thursday, 24 September 2009 00:29:35 UTC