A11y keyboard control AutoComplete Screen Reader User Interaction Challenges

[DaveBest99]

Bug, feature request, or proposal:

Bug: Keyboard accessibility navigation request

What is the expected behavior?

Standard basic keyboard commands, with optional customized hotkeys, should be designed as an integrated strategy for all Angular components. An Angular standard for keyboard commands, HTML page structure layout, and ARIA behaviour will help developers to create a common look and feel across all components and ensure a good user experience. To improve the user experience the Angular components should offer a Context Sensitive Help and consistent error messaging features. Additional component features could be accessed by custom hotkeys or through a Context Menu by pressing Shift+f10 or Right_arrow. The user expected behaviour is learned through consistency and simplicity. For example, if the Autocomplete implementer wishes to use a nonstandard filter, then the component guidelines should instruct the implementer to include text below the Edit Combo box explaining the filter criteria. As the AutoComplete component could be used for many different list selections that require specific filter criteria.

What is the current behavior?

Currently, using JAWS17 on Windows10 with either Firefox, IE11, or Chrome, the basic keyboard commands do not function as expected.

What is the use-case or motivation for changing an existing behavior?

Creating a standard keyboard event handler will improve the user experience for non-mouse users.

Is there anything else we should know?

A11y Issue:
I have tested, using JAWS17, several web pages with the Edit Combo box element using Firefox, Internet Explorer 11, and Google Chrome, with all
having a very different user experience. The best user experience was with Firefox. The AutoComplete basic keyboard commands and focus order does not perform as expected according to WCAG standards. Since the WCAG best practice guidelines are unclear with regard to
AutoComplete keyboard behaviour, I recommend the following:

1. Pressing Tab or Shift+Tab key into the AutoComplete component, the focus lands on the Edit Combo box input field. Upon the first time the input field should be blank (or show a default value), or if the user has previously selected a list item and is returning to the input field, then the selected item should appear in the Edit input field.
   Consider "input" attributes:
   aria-activedescendant=md-input-1
   aria-owns=md-autocomplete-0
   aria-autocomplete=both
   aria-haspopup=false
   aria-label=State
   aria-multiline=false
   autocomplete=both
   dir=ltr
   line-number=1
   role=combobox
   type=text
   spellcheck=false
   title=State
   placeholder=State

2. While the user types text the focus does not move from the Edit input box. Typed characters should appear on the braille display as they are entered, and the screen reader will echo the typed characters according to the user screen reader settings.

3. As each character is pressed, an aria-alert could announce List box results. Example: press "a" and the screen reader announces "4 items found" or "4 items in list", but the focus does not move away from the Edit field so that the user can still see the "a" on the braille display or press Left and Right arrow keys to get verbal feedback as to what is currently in the Edit input field.

4. Pressing Down arrow or Alt+Down_arrow should open the List box with the focus placed on the first item in the list "Alabama" (the Edit input field is no longer visible on the braille display, but instead "Alabama 1 of 4" and the speech output "Alabama 1 of 4").
   Pressing the Tab key moves to the next focusable page element, skipping past the List box.
   Pressing the Shift+Tab key moves to the previous focusable element prior to the AutoComplete element.

5. Pressing the Down arrow the screen reader speech/braille should announce "Alaska".
   Pressing Down arrow again the user should hear/see "Arizona".
   Pressing Down arrow again the user should hear/see "Arkansas".
   Pressing Down arrow again the user should hear/see "Alabama" (focus moves from last item to the first item).
   Pressing Up arrow the user should hear/see "Arkansas" (focus moves from first item to the last item).
   Pressing Home key should move focus to the first List item.
   Pressing End key should move focus to the last List item.
   Pressing the Tab key moves to the next focusable page element after the AutoComplete elemetn.
   Pressing the Shift+Tab key moves to the previous focusable element prior to the AutoComplete element, skipping over the Edit input field.

6. A) Pressing the Enter key on any list item should close the List box, move focus to the Edit input field, and place the selected item in the Edit input field. The Edit input field should have focus and the screen reader will speak the content of the field and show it on the braille display. The user can press Left and Right arrow keys to read the text character by character.
   Pressing Tab key moves focus to the next page element. Note, if an invalid entry has been typed into the Edit input field, or is left blank, an error message should alert the user, and the Edit input field cleared to blank or to the default value. However, if the AutoComplete component is an Editable element, then the text field is left as is and no error message is necessary.

7. B) Or, if the user presses the Escape or Alt+Up_arrow key, then the List box is closed and the focus is moved back to the Edit input field with the originally typed characters. No List item is selected, and the speech out reads the typed characters and shows them on the braille display with the cursor at the end of the character string. The user can press Left and Right arrow keys to read character by character.
   Pressing Tab key moves focus to the next page element. Note, if an invalid entry has been typed into the Edit input field, or is left blank, an error message should alert the user, and the Edit input field cleared to blank or to the default value. However, if the AutoComplete component is an Editable element, then the text field is left as is and no error message is necessary.

8. With the focus on the Edit input field, and the cursor after the "a", the user types "r", then the braille display will show "ar" and the aria-alert will speak "2 items found" or "2 items in the list", but the focus does not move away from the Edit field so that the user can still see the "ar" on the braille display or press Left and Right arrow keys to get verbal feedback as to what is currently in the Edit input field.

9. Pressing Down arrow or Alt+Down_arrow should open the List box with the focus placed on the first item in the list "Arizona" (the Edit input field is no longer visible on the braille display, but instead "Arizona 1 of 2" and the speech output "Arizona 1 of 2").

10. Pressing the Down arrow the screen reader speech/braille should announce "Arkansas".
    Pressing Down arrow again the user should hear/see "Arizona". (focus moves from last item to the first item).
    Pressing Up arrow the user should hear/see "Arkansas" (focus moves from first item to the last item).
    Pressing Home key should move focus to the first List item.
    Pressing End key should move focus to the last List item.

11. A) Pressing the Enter key on any list item should close the List box, move focus to the Edit input field, and place the selected item in the Edit input field. The Edit input field should have focus and the screen reader will speak the content of the field and show it on the braille display. The user can press Left and Right arrow keys to read character by character.
    Pressing Tab key moves focus to the next page element. Note, if an invalid entry has been typed into the Edit input field, or is left blank, an error message should alert the user, and the Edit input field cleared to blank or to the efault value. However, if the AutoComplete component is an Editable element, then the text field is left as is and no error message is necessary.

12. B) Or, if the user presses the Escape or Alt+Up_arrow key, then the List box is closed and the focus is moved back to the Edit input field with the originally typed characters. No List item is selected, and the speech out reads the typed characters and shows them on the braille display with the cursor at the end of the character string. The user can press Left and Right arrow keys to read character by character.
    Pressing Tab key moves focus to the next page element. Note, if an invalid entry has been typed into the Edit input field, or is left blank, an error message should alert the user, and the Edit input field cleared to blank or to the default value. However, if the AutoComplete component is an Editable element, then the text field is left as is and no error message is necessary.

13. With the focus on the Edit input field, and the cursor after the "a", the user presses the Left arrow key and then types "r", then the braille display will show "ra" and the aria-alert will speak "0 items found" or "0 items in the list".
    Note, in an Editable Combo box this is a valid text input, but in a NonEditable Combo box this input is invalid and an user error message may appear or the filter may automatically remove the "a" and report one item in the list ("1 item found" or "1 item in the list").
    Pressing Down arrow or Alt+Down_arrow the List box opens and the focus placed on "Rhode Island" and the screen reader/braille display reports "Rhode Island 1 of 1".

[kara]

Since this is intended to provide supporting information for other issues filed, I'm just going to link to this description in each of the other issues instead. Closing this one so we don't have duplicate tracking.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}