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

• 1 Purpose
• 2 Example: Tree table
• 3 Descendants
  • 3.1 Implementations
  • 3.2 Gaps
  • 3.3 Discrepancies
• 4 Todo
  • 4.1 Initial widget types to document
  • 4.2 Initial toolkits to document
  • 4.3 Template brainstorming

• 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.

• 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.

• 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.

gtk (gail), XUL, Papi

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

None known

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

• 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

• 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?

• 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?