Skip to content
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 doesn't announce dropdown closing for invalid input #3375

Closed
DaveBest99 opened this issue Mar 2, 2017 · 4 comments · Fixed by #3494
Closed

JAWS - Autocomplete doesn't announce dropdown closing for invalid input #3375

DaveBest99 opened this issue Mar 2, 2017 · 4 comments · Fixed by #3494
Assignees
Labels
Accessibility This issue is related to accessibility (a11y) P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@DaveBest99
Copy link

Bug, feature request, or proposal:

Request: Typed input should only match what is in the list box.

What is the expected behavior?

In a non-editable auto-complete, any letters that do not result in a match from the list should be ignored, the drop down list of choices remains static until the user presses Escape to clear the text field, Backspace to remove some of the letters previously typed, or types an additional letter that results in a valid list of choices. In an editable auto-complete, if no choices match the letters typed, the drop down list closes.

What is the current behavior?

Currently anything can be typed into the Edit box.

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

Help users from making mistakes. A non-editable list box should only allow typed text that matches the list items, and an editable list box can accept typed text that does not match the list items, but this is confusing in a list of States.

Is there anything else we should know?

The only time the Edit box gets screen reader focus is when an invalid character is typed. That is, as long as there is a list item with the sequence of typed letters, the focus will move through the list, but a non-recognizable sequence will bring focus to the Edit box. Deleting the last letter typed (pressing Backspace) will move focus to the valid list item but it is not announced by the screen reader. That is, the screen reader user does not know what list item has focus (Note,although JAWS does not announce the State name, it is showned on the braille display). The user can press up/down arrow keys through the list but never get Edit box focus. Focus should stay on the Edit box until the arrow key is pressed, and an aria-alert can read the list item in focus.

@kara kara added the Accessibility This issue is related to accessibility (a11y) label Mar 2, 2017
@kara kara self-assigned this Mar 3, 2017
@kara
Copy link
Contributor

kara commented Mar 3, 2017

Related: Related: #3416

@kara
Copy link
Contributor

kara commented Mar 4, 2017

Currently we hide the panel when there are no options, but it looks like aria-expanded is not updated properly, so there's no indication that the list is closed. That's definitely a bug. It's also weird when the invalid letter is deleted because it doesn't announce that the list has re-opened. Looking into it.

@kara kara changed the title A11y keyboard control AutoComplete input validation A11y - Autocomplete doesn't announce dropdown closing for invalid input Mar 4, 2017
@kara kara added the P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent label Mar 4, 2017
@DaveBest99
Copy link
Author

DaveBest99 commented Mar 4, 2017 via email

@kara kara changed the title A11y - Autocomplete doesn't announce dropdown closing for invalid input JAWS - Autocomplete doesn't announce dropdown closing for invalid input Mar 10, 2017
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Accessibility This issue is related to accessibility (a11y) P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants