Tracker: a11y / accessibility tools

[dhardy]

• Tab key navigation
• Tab key should navigate groups, arrows within groups #524
• Access keys
• Contextual keyboard actions (e.g. arrow keys on a slider)
• Screen reader / external widget introspection read support
• Read support for text inputs (bug; see below and kas-text update; use child Role::TextRun for input fields #528)
• Widget action support for accessibility tools (e.g. button activation, value setting, scrolling)

---

This likely means using https://github.com/AccessKit/accesskit/

[dhardy]

Known missing widget details from the current implementation:

• Text widgets do not report glyph positions to AccessKit (and thus do not support coordinate-to-text-index translation in accessibility tools)
• Text widgets do not report text selection
• Lists with selectable children should use role List and place their children in a ListItem node
• Tables should use role Table, have RowHeaders and ColumnHeaders and wrap children with Cells; we don't have a real table widget yet though

[DataTriny]

Lists with selectable children should use role List and place their children in a ListItem node

If you're talking about AccessKit roles, the ones to use here are Role::ListBox and Role::ListBoxOption. You'll also want to call Node::set_size_of_set on the listbox node and Node::set_position_in_set on the items.

[dhardy]

#521 adds AccessKit integration. Known issues:

• Usage of access keys does not set focus for CheckButton and other widgets with separate access label #522
• Some widgets should use accesskit::Role::GenericContainer
• Text input content should use children with Role::TextRun
• Add tab bar and tab pane #525
• Navigable widgets should advertise support for accesskit::Action::Focus
• Should all widgets support Action::ScrollIntoView?
• Lists of selectable children should use Role::ListBox (see above comment)

[dhardy]

@DataTriny is Role::MenuItemCheckBox substantially different from CheckBox? What expectations are there on MenuItem items?

[dhardy]

If you're talking about AccessKit roles, the ones to use here are Role::ListBox and Role::ListBoxOption. You'll also want to call Node::set_size_of_set on the listbox node and Node::set_position_in_set on the items.

How does this work with virtual scrolling (when very large numbers of items may belong to the list, but not all of those items are on screen)? In the case of kas::view::ListView, a virtual index (often but not always usize) is used as a persistent key for items which may disappear from view (filtered out or simply scrolled out of view). Also, the full size of the list may not be known; the current API needs to change and will become something like Iterator::size_hint. So size_of_set and position_in_set properties could be used in some cases, but are not flexible enough to handle all cases.

Alternatively, I could make ListView report the size and index as items appear on screen now. In that case the set size and position-in-set of items will change frequently, e.g. when scrolling.

[DataTriny]

How does this work with virtual scrolling (when very large numbers of items may belong to the list, but not all of those items are on screen)?

In this case you must call Node::set_clips_children on the listbox. At this point we will filter out from the accessibility all children that fall outside of the listbox bounds, except for the first and/or last that are close to the edges. Therefore you can skip the rest of the children on your side if you want. You probably also want to call Node::add_child_action(Action::ScrollIntoView) again on the listbox, this way ATs can scroll the list by calling the scroll into view on the items that are just above/below the listbox bounds. If there is no easy way to know the number of items in advance, it can be acceptable to not provide the information.