Accessibility/JSON ARIA: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(New page: =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: ...)
 
No edit summary
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.


==Why do we need this?==
=Why do we need this?=


ARIA role & property extensibility will be important for things such as:
ARIA role & property extensibility will be important for things such as:
Line 12: Line 12:
* Diagrams, where the visual appearance (color, dashed lines, whatever) often indicate properties
* Diagrams, where the visual appearance (color, dashed lines, whatever) often indicate properties


= Authoring new roles =
== Pointing to new roles definitions from within document content==
== Pointing to new roles definitions from within document content==


Line 90: Line 91:
}
}
</pre>
</pre>
= End user experience =
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
= Accessibility API Support (ATK/AT-SPI and IAccessible2)
Need to fill this out -- the idea is to use object attributes.

Revision as of 17:02, 6 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 indicate 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 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" ]]
    ]
}

End user experience

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

= Accessibility API Support (ATK/AT-SPI and IAccessible2)

Need to fill this out -- the idea is to use object attributes.

Retrieved from "https://wiki.mozilla.org/index.php?title=Accessibility/JSON_ARIA&oldid=73361"