Review combobox design pattern (initial draft)

[mcking65]

A first draft of the combobox design pattern
specified in issue #31 is now merged into master and ready for review.

Reviews requested as of September 21, 2017

Input is appreciated from all task force members as well as other interested people. Comments on this issue are specifically requested from:

• Review by Aaron (@aleventhal)
• Review by Ann (@annabbott)
• Review by Bryan (@accdc)
• Review by James (@jnurthen)
• Review by Jemma (@a11ydoer)

[a11ydoer]

@mcking65 I have reviewed combo box design pattern. This explains clearly various combo box autocomplete patterns. One thing from the draft is that the "escape" should be "enter" if a user decide to keep the current value"

I copied the section for your info.

" A feature that distinguishes both combobox and menu button from listbox is that they can enable users can navigate the set of allowed values and, at any point, decide to keep the current value by pressing escape."

[a11ydoer]

@mcking65 While I skimmed through keyboard interaction section. I was thinking whether we can make this more concise; omit the same keyboard functionality, which is repeated over the pattern and mention only different keyboard functionality . Thanks for the great work, Matt.

[annabbott]

For Tree Popup Keyboard Interaction > Note > item 3 > third bullet:
In either case, focus is fisually distinct from selection so users can readily see if a value is selected or not.

Typo: change "fisually" to "visually"

[annabbott]

For Listbox Popup Keyboard Interaction and Grid Popup Keyboard Interaction:
Delete (Optional): Returns focus to the textbox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.

Suggest replacing "state" with "value".

[annabbott]

Under WAI-ARIA Roles, States, and Properties:
When the combobox popup is not visible, the element with role combobox has aria-expanded set to false. When the popup element is visible, aria-expanded is set to true. Note that Elements with role combobox have a default value for aria-expanded of false.

Typo: last sentence > change "Elements" to "elements" (no upper case 'e')

[annabbott]

Under WAI-ARIA Roles, States, and Properties > The textbox element has aria-autocomplete set to a value that corresponds to its autocomplete behavior > third bullet:
both: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox. In addition, the portion of the selected suggestion that has not been typed by the user, a completion string, appears inline after the input cursor in the textbox. The inline completion string is visually highlighted and has a selected state.

Typo: remove the comma after "a completion string,"

[annabbott]

Note following WAI-ARIA Roles, States, and Properties:

Listbox Roles, States, and Properties
Grid Roles, States, and Properties
Tree Roles, States, and Properties
Dialog Roles, States, and Properties

The above should probably be included in the Note and have the same green background as the Note.

[error404as]

Please clarify the behavior of the button, next to combobox input. Does it open the whole options list or only filtered ones according to current input value?
Should the button be still in tab order when user potentially completed his input? Case when user typed something and pressed Tab. It'll be better to give let him go to the next form field, not annoying with extra Tab-able control. To my mind button should be in tab order only while no value is provided in the combobox input.

[accdc]

It looks good, though I have a question about this one:

"List autocomplete with automatic selection: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox, and the first suggestion is automatically highlighted as selected. The automatically selected suggestion becomes the value of the textbox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the textbox."

If this is implemented in accordance with the spec, the suggested options, or even the presence of a list of suggested items is never actually announced to screen reader users when typing, so it is often impossible for such users to even be aware that these lists are available or if there is anything being suggested. On touch devices like iOS for example, a person can type whole strings using the touch keyboard and never be aware that anything is being dynamically suggested on the screen. At present the only way to make this work reliably is to use a live region or to implement a dynamic message such as unobtrusive announcement to make this work. (E.G https://github.com/accdc/aria-announce )

So if such comboboxes are implemented as documented here yet fail to provide notification to screen reader users that dynamic content changes have occurred, it results in significant accessibility issues for these users regardless, which will definitely be flagged in accessibility audits.

[mcking65]

Bryan, first, thank you for the review!

@accdc commented:

I have a question about this one:

List autocomplete with automatic selection: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the textbox, and the first suggestion is automatically highlighted as selected. The automatically selected suggestion becomes the value of the textbox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the textbox.

If this is implemented in accordance with the spec, the suggested options, or even the presence of a list of suggested items is never actually announced to screen reader users when typing, so it is often impossible for such users to even be aware that these lists are available or if there is anything being suggested.

Exactly. Shortcomings in screen reader behavior, like this one, are one of the primary drivers of all this work on practices.
There is no reason screen readers cannot provide robust and user-friendly experiences for comboboxes that have this very common form of autocomplete.
As long as the combobox implements the ARIA correctly, as is being done in the examples, we should be able to one day have fabulous experiences for this kind of autocomplete.

On touch devices like iOS for example, a person can type whole strings using the touch keyboard and never be aware that anything is being dynamically suggested on the screen. At present the only way to make this work reliably is to use a live region or to implement a dynamic message such as unobtrusive announcement to make this work. (E.G https://github.com/accdc/aria-announce)

Yap, this is another example of how authors are doing extra work that should be completely unnecessary! It is just one more reason that accessible experiences are more expensive than they should be. But, this guide is a step toward changing that.

So if such comboboxes are implemented as documented here yet fail to provide notification to screen reader users that dynamic content changes have occurred, it results in significant accessibility issues for these users regardless, which will definitely be flagged in accessibility audits.

True enough; authors will have to do lots of extra work until assistive technology developers work on improving their experiences for ARIA. There are probably at least a hundred examples of problems like this once we work through all the combinations of screen readers, browsers, and patterns. And, doing that is one of my ambitions as soon as our examples are adequately reviewed.

[mcking65]

Commit 9fda46b addresses feedback received thus far. Given the length of the pattern and number of changes, here is a summary of major changes (typo fixes not included) to help facilitate review.

Change 1: Revise description of popup display conditions

To help address questions raised by @error404as, changed:

The popup is hidden by default, and the conditions that trigger its display are specific to each implementation. For example, some implementations do not display suggested values for the textbox in the popup until several characters are typed in the text box. While in other implementations, the popup is displayed when the textbox receives focus.

Replaced with:

The popup is hidden by default, and the conditions that trigger its display are specific to each implementation. Some possible popup display conditions include:

• It is displayed only if a certain number of characters are typed in the textbox and those characters match some portion of one of the suggested values.
• It is displayed as soon as the textbox is focused, even if the textbox is empty.
• It is displayed when the Down Arrow key is pressed or the “show” button is activated, possibly with a dependency on the content of the textbox.
• It is displayed if the value of the textbox is altered in a way that creates one or more partial matches to a suggested value.

Change 2: Clarify paragraph about listbox and menu button

A comment by @a11ydoer made it clear that this text is not sufficiently clear:

A feature that distinguishes both combobox and menu button from listbox is that they can enable users can navigate the set of allowed values and, at any point, decide to keep the current value by pressing escape. In contrast, navigating a listbox immediately changes its value, and escape does not provide an undo mechanism.

So, I changed it to:

One feature that distinguishes both combobox and menu button widgets from listbox widgets is their ability to provide an undo mechanism. In many implementations, users can navigate the set of allowed values in a combobox or menu and then decide to revert to the value the widget had before navigating by pressing escape. In contrast, navigating a listbox immediately changes its value, and escape does not provide an undo mechanism.

Change 3: Weaken recommendation to use 1.1 pattern

Based on concerns raised by @accdc when reviewing examples, replaced this paragraph:

The options for a combobox to popup a grid, tree, or dialog were introduced in ARIA 1.1. Changes made in the ARIA 1.1 specification also add support for a code pattern that enables assistive technologies to present the textbox and popup as separately perceivable elements. While the ARIA 1.1 pattern is recommended, both patterns are described in the following sections, and there are no plans to deprecate the ARIA 1.0 pattern.

With this new version that emphasizes the need for sufficient assistive tech support for the 1.1 pattern:

The options for a combobox to popup a grid, tree, or dialog were introduced in ARIA 1.1. Changes made in the ARIA 1.1 specification also add support for a code pattern that enables assistive technologies to present the textbox and popup as separately perceivable elements. both ARIA 1.0 and 1.1 patterns are described in the following sections. While using the ARIA 1.1 pattern is recommended as soon as assistive technology support is sufficient, there are no plans to deprecate the ARIA 1.0 pattern.

Change 4: Restructure notes for states and props

In response to feedback from @annabbot regarding the styling of the notes for roles, states, and properties, restructured so the CSS note class could encompass the entire set of notes.

[a11ydoer]

@mcking65 Thanks for all the changes you made. It sounds more clear now. Great job!

[mcking65]

Thank you everyone for contributing to this pattern! This was one of the more challenging patterns, and we got it done! Thank you!!