New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review combobox design pattern (initial draft) #464

Closed
mcking65 opened this Issue Sep 22, 2017 · 13 comments

Comments

@mcking65
Contributor

mcking65 commented Sep 22, 2017

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:

@a11ydoer

This comment has been minimized.

Show comment
Hide comment
@a11ydoer

a11ydoer Sep 25, 2017

Contributor

@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."

Contributor

a11ydoer commented Sep 25, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@a11ydoer

a11ydoer Sep 25, 2017

Contributor

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

Contributor

a11ydoer commented Sep 25, 2017

@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 annabbott closed this Oct 2, 2017

@annabbott

This comment has been minimized.

Show comment
Hide comment
@annabbott

annabbott Oct 2, 2017

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 commented Oct 2, 2017

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 annabbott reopened this Oct 2, 2017

@annabbott

This comment has been minimized.

Show comment
Hide comment
@annabbott

annabbott Oct 2, 2017

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 commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@annabbott

annabbott Oct 2, 2017

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 commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@annabbott

annabbott Oct 2, 2017

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 commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@annabbott

annabbott Oct 2, 2017

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.

annabbott commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@error404as

error404as Oct 13, 2017

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.

error404as commented Oct 13, 2017

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.

mcking65 added a commit that referenced this issue Oct 16, 2017

Combobox Pattern: Remove Windows Specific Keyboard Interactions for T…
…extbox

For issue #413, Modified the combobox pattern in aria-practices.html:

1. Delete all the Windows-specific key assignments from the textbox subsection of the keyboard interaction section.
2. Add a note recommending reliance on browser for text editing functionality.

Also related to issue #464.
@accdc

This comment has been minimized.

Show comment
Hide comment
@accdc

accdc Oct 27, 2017

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.

accdc commented Oct 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mcking65

mcking65 Oct 30, 2017

Contributor

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.

Contributor

mcking65 commented Oct 30, 2017

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 added a commit that referenced this issue Oct 30, 2017

Combobox Design Pattern: Address Feedback Received Through Oct 29
For issue #464, made the following changes to
the combobox design pattern section in aria-practices.html:

1. Revise description of popup display conditions
2. Clarify  paragraph about listbox and menu button
3. Weaken recommendation to use 1.1 pattern
4. Restructure notes for states and props
5. Fix multiple typos
@mcking65

This comment has been minimized.

Show comment
Hide comment
@mcking65

mcking65 Oct 30, 2017

Contributor

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.

Contributor

mcking65 commented Oct 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@a11ydoer

a11ydoer Nov 17, 2017

Contributor

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

Contributor

a11ydoer commented Nov 17, 2017

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

mcking65 added a commit that referenced this issue Nov 20, 2017

Combobox Design Pattern: Complete Task Force Review Process
Modified aria-practices.html to remove link to issue #464 from the combobox design pattern section.
The internal task force review process is complete.
@mcking65

This comment has been minimized.

Show comment
Hide comment
@mcking65

mcking65 Nov 21, 2017

Contributor

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

Contributor

mcking65 commented Nov 21, 2017

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

@mcking65 mcking65 closed this Nov 21, 2017

Combobox Patterns and Examples Development Project automation moved this from In Progress to Complete Nov 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment