Re: aria mappings

On Wed, Sep 23, 2009 at 1:26 PM, Nick Fitzsimons <> wrote:

> Given that these controls are expected to be implemented as native
> controls, there surely isn't any requirement to expose an ARIA role
> property.

The aria strategy seems to be having the web browser map from aria to
an underlying OS accessibility layer.  This works for screen readers
that don't want to (have to) know anything about specific applications
(including the web browser).

But it limits the potential of software aids, which might be written
in javascript or other extension languages.

> 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.

Even leaving aside the decision of whether to expose the roles (vs
requiring assistance software to keep its own lists of special element
names), the semantics are *not* defined except by this spec.  This
spec is responsible for saying whether or not the <input
type=checkbox> qualifies as aria role=checkbox.

> 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).

Right; authors of individual pages should not have to write redundant
attributes.  But the spec does have to explicitly define them.

I personally also believe that the DOM should also expose them
consistently with the way explicitly set user properties are exposed,
so that the mapping can be maintained by the browser rather than each
little helper application.

I personally also believe that the default values should be visible to
CSS, so that authors will be encouraged to style based on something
that is accessible.  (This does go against the grain of CSS, which
assumes that default values may not be available.)

> 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.

That works for external hardware, and to some extent for software that
installs itself as a driver.  It is not sufficient for software that
runs within the browser.


Received on Thursday, 24 September 2009 00:47:04 UTC