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 indicate properties

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 ARIUA 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" ]]
    ]
}

Accessibility/JSON ARIA

Role extensibility

Why do we need this?

Pointing to new roles definitions from within document content

Using the widget

Definining the widget