-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
JAWS - Autocomplete edit box announcement is confusing #3374
Comments
@DaveBest99 To clarify, on a screenreader, you'd want the experience to be:
Is that right? We do currently keep the focus on the text field as you're typing, even if you hit an arrow key. What we're switching is the aria-activedescendant element. Clearly this isn't doing what we expect, so I want to make sure that we have the expected experience right for testing. |
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. 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.
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").
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).
6A. 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.
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.
6B. 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.
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. 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.
8. 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").
9. 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).
10A. 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.
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.
10B. 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.
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.
11A. 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".
David
From: Kara [mailto:[email protected]]
Sent: March 2, 2017 09:16 PM
To: angular/material2
Cc: David Best; Mention
Subject: Re: [angular/material2] A11y keyboard control AutoComplete nonstandard filter selection (#3374)
@DaveBest99 <https://github.com/DaveBest99> To clarify, on a screenreader, you'd want the experience to be:
1. Type "a" --> hear "A" announced, then "3 dropdown items in list"
2. Type "r" --> hear "R" announced, then "1 dropdown item in list"
3. Type DOWN arrow -> hear "Arizona"
Is that right? We do currently keep the focus on the text field as you're typing, even if you hit an arrow key. What we're switching is the aria-activedescendant element. Clearly this isn't doing what we expect, so I want to make sure that we have the expected experience right for testing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#3374 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AVPBNp-Yv2ShCa485a9eEBCaZvugc0roks5rh3fXgaJpZM4MQhnq> . <https://github.com/notifications/beacon/AVPBNgpDYFnxumDW4xX_9WzR3KNubQJ0ks5rh3fXgaJpZM4MQhnq.gif>
|
Related: #3416 |
@DaveBest99 Thanks for all the detail! I tested steps # 1-5 again on JAWS on Firefox (leaving other steps for the scope of other existing issues) to break down what I think is still broken. Here's what I'm finding: Step 1: This seems to work. Tabbing to the autocomplete announces "State edit combo expanded. To set the value...". Or if there is a value already set, I hear "State edit combo expanded. California. To set the value..." Step 2 This seems to work. Typing a letter does announce that letter in the screenreader. Step 3: This is broken. Currently we don't announce "4 items found" or "4 items in list" as the user types. Also hitting the LEFT or RIGHT arrow keys does not read the input, but rather reads something that sounds like "length". Both those things should be fixed. Step 4: This seems to work. Hitting DOWN arrow or ALT-DOWN arrow both announce "List box: Alabama, 1 of x". Step 5: This seems to work. Subsequent DOWN keypresses result in "Arizona", then "Arkansas", etc. So it seems the two things in the scope of this Github issue are:
Let me know if I'm misunderstanding anything from above. Will tackle steps 6 - 10 in other issues. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug, feature request, or proposal:
Request: Change filter list selection to the expected standard.
What is the expected behavior?
With focus in the text box, with an existing value, type additional letters. As the user types letters the list of choices is filtered so that only those that begin with the typed letters are displayed. Until the user presses the Down arrow keys to highlight a particular choice, only the typed letters are displayed in the text box.
What is the current behavior?
Currently the screen reader cannot see what has been typed in the Edit box, and the drop-down list appears to be random.
What are the steps to reproduce?
Use a screen reader and keyboard.
What is the use-case or motivation for changing an existing behavior?
To be more inclusive of keyboard users and those who have cognitive disabilities.
Is there anything else we should know?
Although screen reader focus never shows the Edit box, the user can type letters and the focus moves to the next list item with that letter. There is no way for the user to see what has been typed in the Edit box. Focus does not stay in the Edit box until an arrow key is pressed. Aria-alert could be used to announce the list item without moving the focus from the Edit box.
The text was updated successfully, but these errors were encountered: