Accessibility/JSON ARIA
Role extensibility
This is a proposal for how authors could define new ARIA widgets.
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:
- Vendor-specific widgets
- New innovations
- 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
This is a rough proposal for what the community may decide is not necessary, and even if we do it, we'll be waiting until after ARIA 1.0.
- There is still skepticism of whether this is necessary
- There are proponents of it among the vendor and accessibiltiy communities
- The idea has been run by the leads on Firefox accessibility, as well as the Orca and NVDA screen reader projects, and they believe it is feasible
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
Pointing to new roles definitions from within document content
<head> <link rel="ARIA" href="http://www.myroles.org/buddy.json"/> <link rel="ARIA" "http://www.myroles.org/buddylist.json"/> <!-- Optional: pull l10n into separate files --> <link rel="ARIA-l10n" href="http://www.myroles.org/buddy-l10n.json"/> <link rel="ARIA-l10n" href="http://www.myroles.org/buddylist-l10n.json"/> </head>
Authoring content with the new widget
<div role="buddylist listbox secondary"> <div role="buddy option" aria-away="true" aria-idle="3 hours, 22 minutes" aria-where="mobile" aria-friends="somefriend"/>
The author only needs to include the fallback role that we inherit from (in this case listbox or option) if they need support for browser version that support ARIA but don't support role extensibility. Browsers that support role extensibility should utilize the "inherits" field from the JSON file.
If you care about validation, you need to write a DTD or schema that handles the new properties.
Definining the widget
Example: buddy widget The definition is in a JSON file, which is easy for any modern browser to parse into an object.
{
<!-- Role and property definition -->
"role": "buddy",
"inherits": "listbox",
"nameOkFromContents": true, <!-- can the accessible name be computed from the content subtree (e.g. no for a container like a tree, usually yes for a focusable widget) -->
"liveProperties" [ <!-- AT should notify user of changes if it is in a live region or has focus -->
<!-- prop attribute name, data type -->
[ "away", "boolean" ],
]
"activeProperties": [ <!-- AT should notify user of changes if the object has focus-->
<!-- prop attribute name, data type -->
[ "activity", "string", "What is this user doing?" ],
],
"passiveProperties": [ <!-- AT should not notify user of changes, but should still present them if the containing object receives focus -->
<!-- prop attribute name, data type -->
[ "idle", "string" ], <!-- readable string -->
[ "where", [ "pc", "mobile", "blackberry"] ], <!-- 3 legal programmatic tokens -->
[ "friends", "IDREF" ], <!-- custom relation -->
]
<!-- Localization info: can be split into a separate file -->
"localizedRole": "Buddy",
"localizedProperties": [
<!-- Do these need to specified for attributes with boolean or token values? -->
"friends", "Friends with"
]
"localizedValues": [
<!-- localization for values (booleans and tokens) -->
<!-- String values are already localized by their nature -->
<!-- IDREF/IDREFS (relations) should be localized -->
[ "away", [[ "true", "Currently away"],
[ "false", "Available" ]].
[ "where", [[ "pc", "At desk" ],
[ "mobile", "On phone"],
[ "blackberry", "On blackberry" ]]
]
}
End user experience
Screen reader users
Screen reader users would be able to hear the role of the new type of object, and associated properties.
Property changes:
- If the object is focused, then any properties in the activeProperties or liveProperties would be spoken
- If the object is not focused, then any properties in the liveProperties would be treated as a polite change
Alternative input
(To do)
How to process
There are 3 ways an AT can handle a new role:
- just fall back on the role it inherits from
- via special code for new role
- If role becomes popular, core AT code can deliver support
- User or vendor-defined AT scripts that operate on a per-webpage or per-role basis
- use the provided JSON semantics for the role and its properties
Accessibility API Support (ATK/AT-SPI and IAccessible2)
Need to fill this out -- the idea is to use object attributes and events to indicate changed attributes.