Accessible widgets best practices

When implementing the accessibility representations for widgets, it is good if all implementations follow some schemes. To make it easier for the client side, we propose a few ways of representing widgets where the structure is not really clear.

Below we use the AT-SPI role to denote items. Each item has to be there exactly once, unless marked with + for 1 to many or * for 0 to many.

DONE:

Menus

This is mostly for the menu bar of an application - File, Edit etc.

• menu bar

  • menu*

    • menu* can contain more menu and menu item

    • menu item*

There is one menu bar as root element, it has any number of menu as children. menu can have menu and menu item as children. menu item does not have children.

Combo Boxes

• combo box

  • menu must have exactly one menu as child

  • text[0-1] text represents editable combo box and is optional

The Accessible Name of the combo box accessible is the current text that is displayed. This text can be typed by the user or one of the selected items.

IN PROGRESS:

List

• list

  • list item*

A list has only one column. It contains items.

Table

current state in gtk: it would be difficult to provide row objects

• table

  • table column header

  • table cell sometimes gtk has image+text in one cell. it represents that as two child objects of type table cell

Web: firefox usually has rows, but sometimes it can happen that rows are not present (like html role presentation or css hidden)

• table

  • table row the first row only contains headers

    • table row header once for the top-left header

    • table column header* as many as columns

  • table row*

    • table row header[0-1] for the left header

    • table cell* as many as columns, can be less if cell-span > 1

should headers be mandatory? should it be table header row for the first row?

IA2: all cells are children of the table object. there are no row objects. like gtk.

One big concern was notifications about selection changes. It would be great to get notified for things such as row selected. There are two ways to tackle this: in the first approach (gtk) we could define a signal: rows-selected() and rows-deselected or somesuch in the second approach with rows, the row object could be sent as selected. this has the downside that there is no way to do the same for columns. it is less flexible. IA2 has functions to get selected rows/columns

Trees

The reason for the variety of trees that are possible is mostly that ARIA has very flexible tree definitions. The web implementators will simply expose that.

Tree has exactly one column. For trees with more than one column the tree table has to be used.

Tree items can contain a grouping element. In the grouping element it can have other items.

Tree 1: define hierarchy through relations and group positions

• tree

  • tree item with relations and group positions that define hierarchy

  • tree item

  • ...

This tree works with add/remove tree items when they get expanded/collapsed.

Tree 2: real hierarchy

The items are arranged as children.

• tree

  • tree item* with parent child relations to describe hierarchy

    • tree item*

• tree

  • tree item group

    • tree item* with parent child relations to describe hierarchy

      • tree item group

        • tree item*

No need for add/remove for expanding/collapsing of sub items.

Tree 3: Tree Table

Tree tables can not be hierarchical. tree table can have more than one column

• tree table

  • tree table cell*

• tree table

  • tree table row*

    • tree table cell*