346
edits
| 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. | ||
= | =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. | ||
ARIA role & property extensibility can be useful for things such as: | |||
ARIA role & property extensibility | |||
* Vendor-specific widgets | * Vendor-specific widgets | ||
edits