Accessibility/JSON ARIA: Difference between revisions

Jump to navigation Jump to search
Line 3: Line 3:
This is a proposal for how authors could define new ARIA widgets.
This is a proposal for how authors could define new ARIA widgets.


=Why do we need this?=
=Do we need this?=
 
No one wants useless bloat, so the plan is to let ARIA 1.0 settle in and prove that it's necessary and usable via prototyping.


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.
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 can be useful for things such as:
 
ARIA role & property extensibility will be important for things such as:


* Vendor-specific widgets
* Vendor-specific widgets
346

edits

Navigation menu