346
edits
Changes
no edit summary
=Why do we need this?=
The basic problem is that every accessibility API today has a predefined set of roles and properties. However, because authors are always creating new things, they end up forcing using the existing semantics in innappriate ways, just to get the behavior they want in one or two ATs they test with.
Why not use the ability to define a new role as inheriting from a known one, the new properties it has? It is possible to specify what to do with the new properties (deal with value typing, localizations and changes).
ARIA role & property extensibility will be important for things such as:
* Areas that are too detailed and specific for standardization, but useful for accessibility (such as buddylists or scheduling widgets)
* Diagrams, where the visual appearance (color, dashed lines, whatever) often indicates properties
=Status of the discussion=
Currently there is still skepticism of whether this is necessary, but there are proponents of it among the vendor and accessibiltiy communities.
We will be looking to get as many use cases that we can -- specifically we'll need widgets that ARIA 1.0 does not cover which this technology would help define.
= Authoring new roles =
