Tree-based Select Widget Implementation Example

water buffalo
mountain lion
pit bull
tyrannosaurus rex

A link that doesn't go anywhere, after the widget, as an anchor to test tabbing through or out of the widget.

Testing Results and Commentary

Note on Windows High Contrast Mode (HC): To make selections more visually distinct when HC is enabled, an underline displays. We ensure icon visibility by setting forced-color-adjust: auto in the SVG style attribute and setting the property fill='currentColor' on the path.

Environment: Testing conducted May, 2022. All technologies evaluated at most recently released versions.

Summary: Tree has strong support across screen readers, with only a few non-optimal behaviors, as noted in the screen reader + browser pairing listed below. The single exception is macOS VoiceOver, which incorrectly reports the tree as a table structure. If there is a need for a select-style menu where the “groups” must be collapsible, a tree implementation would provide a solid experience, with the exception that the mobile screen readers tend not to report cardinality and lean on aria-describedby for signifying group affiliation. Even with these limitations, the widget would be comprehensible and usable for most proficient screen reader users, barring the exeption of unusable performance encountered with macOS VoiceOver. Because of Mac VoiceOver's unacceptable performance, the tree-based implementation should not be used in production.

Note: If this widget were used along with a dynamic search, an appropriate aria-live announcement of number of results returned would be something like “X selectable items, in Y groups.” It would be ideal to have all selectable items be at level two, nested within a group. That way, when the user entered the tree they would immediately be oriented by hearing the number of groups (all of the expandable tree items at level one).