Accessibility/JSON ARIA: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 105: | Line 105: | ||
(To do) | (To do) | ||
= Accessibility API Support (ATK/AT-SPI and IAccessible2) = | = 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. | Need to fill this out -- the idea is to use object attributes and events to indicate changed attributes. | ||
Revision as of 17:27, 9 November 2007
Role extensibility
This is a proposal for how authors could define new ARIA widgets.
Why do we need this?
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
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>
Using the 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.