Accessibility/ATK/AT-SPI/AT-SPI Best Practices

Contents

if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); }

Purpose

  • To document how common widgets are exposed via AT-SPI across applications and toolkits.
  • To minimize descrepancy among common accessible widget implementations.
  • To provide a reference for developers who wish to implement accessibility for new toolkits or custom widgets using ATK or similar APIs.
  • To provide a reference for AT developers who wish to provide a consistent user experience across applications.

Example: Tree table

Role
tree table
States
focusable, focused, manages descendants, visible, showing
Subinterfaces
table, selection, component
Relations
Events
  • focus (source: tree table)
  • object:active-descendant-changed (source: table cell)
Notes
Table cell accessibles are exposed as immediate children of the top table accessible.

Descendants

Role
table cell
States
visible, showing
Subinterfaces
text, image (both optional)
Relations
node child of (on all cells in the first column pointing to tree parent nodes)
Events
  • etc.
Notes
Columns containing more than one type of widget are represented by an accessible having a number of accessible children equal to the number of packed widgets. For instance, if an icon and text are packed into the same tree cell, the icon and text widgets are represented by two accessible children below a dummy parent representing the entire cell.

Implementations

gtk (gail), XUL, Papi

Gaps

  • Roles to distinguish non-trivial cells (check box, combo box)
  • Ability to get peer and child counts for a given tree level.

Discrepancies

None known

Todo

  1. develop a standard template for writing descriptions
  2. develop a layout for the site (widget type then toolkit? toolkit then widget type?)

Initial widget types to document

  • common chrome widget types
    • trivial: button, menu item, sliders, progress bars, radio buttons, labels, check boxes, images
    • widget containers: menu bars, menus, tabbed panels
    • editables: text entries, text boxes
    • item containers: list boxes, tables, trees, tree tables
    • complex: combo boxes, autocompletes, spin buttons
    • indicators: progress bars, sliders
  • common document types

Initial Toolkits to Document

  • gail implementations for gtk widgets
  • Firefox implementations for XUL widgets, HTML widgets

Do we want to redocument all information for all toolkits even when it's the same? Do we want to document gail as standard and other toolkits as deviations?

Template brainstorming

  • name of the widget
  • known accessible implementations by toolkit/application
  • name of the toolkit/application
  • relevant toolkit/application version info
  • accessibility information
    • events fired, when fired (if possible to note)
    • event data (at-spi source, detail1, detail2, any_data)
    • subinterfaces
    • common relations
    • common action names
    • common object attributes
    • missing information
    • discrepancies from the norm
    • potential improvements
  • pointers to other doc about keyboard accessibility (Aaron Leventhal's suggestion)

Can we effectively use MediaWiki's template feature to cut down on the amount of work involved if we ever change the format of our template?

Groups: