346
edits
Changes
→Do we need this?
This is a proposal for how authors could define new ARIA widgets.
=Do we need Problem statement= The basic problem is that every accessibility API today has a predefined set of roles and properties. Historically, because developers are always creating new things, they end up forcing the new semantics into the existing semantics in inappropriate ways, just to get the behavior they want in one or two ATs they test with. This degrades the accessibility API over time as other ATs end up writing special case code for the various semantics on a per-application basis. For example, an application may make their software work alright with JAWS, by putting additional status information into aria-describedby. However, this?will not work well with changes to the status if the widget is later used dynamically, and will not work with alternative input technology. Another issue is that standards bodies are slow, and that proprietary vendors do not want to spend the resources to painfully push their new ideas through the standards. In addition, it can be a problem to share IP in the new widgets before the release of a new product. == Use cases ==
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.
* Vendor-specific widgets
