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

Auto-complete is not screenreader accessible #20099

Closed
bhavyarm opened this issue Jun 20, 2018 · 5 comments
Closed

Auto-complete is not screenreader accessible #20099

bhavyarm opened this issue Jun 20, 2018 · 5 comments
Labels
bug Fixes for quality problems that affect the customer experience Project:Accessibility Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. WCAG A

Comments

@bhavyarm
Copy link
Contributor

Kibana version: 6.3.0

**Browser version:**chrome latest

Browser OS version: os x

Original install method (e.g. download page, yum, from source, etc.): from downloads

Describe the bug: With KQL switched on - if you start typing your search query term in search bar - screenreader announces what you are typing but there is no indication that user can select query terms with auto-complete.

Steps to reproduce:

  1. Use voiceover
  2. Switch on query options for KQL
  3. Start typing - non-sighted user will not know that there are auto-complete options available.

Screenshots (if relevant):
auto_complete

@bhavyarm bhavyarm added bug Fixes for quality problems that affect the customer experience Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. :Discovery Project:Accessibility WCAG A labels Jun 20, 2018
@Bargs
Copy link
Contributor

Bargs commented Jul 5, 2018

I took a swing at this today but couldn't manage to get it working. I tried using aria-owns but didn't have any luck with it. There might be better options or I may have been using it incorrectly. There are probably more significant changes that need to be made though, I noticed the auto complete options aren't read out even when you focus them with the keyboard. Someone with more accessibility experience than myself will probably have better luck.

Note that this problem exists for KQL and lucene, it's just more obvious with KQL since lucene only uses the typeahead to display recent searches.

@bhavyarm
Copy link
Contributor Author

bhavyarm commented Jul 9, 2018

@aphelionz do you have any inputs? cc @timroes / @rayafratkina / @AlonaNadler Thanks!

@timroes
Copy link
Contributor

timroes commented Jul 9, 2018

For auto completion using aria-activedescendant is usually the best choice, since that tells the a11y software, that another element is actually the currently focused one, than the one that has the focus.

You can have a look at the timelion autocompletion which should be accessible: https://github.com/elastic/kibana/blob/master/src/core_plugins/timelion/public/directives/timelion_expression_input.html#L29

The general working:

  • Give the encapsulating parent element (that contains the input and the auto suggestions):
    • role="combobox"
    • aria-expanded=true/false (depending on whether the auto completion is currently showing or not)
    • aria-haspopup="true" (always!)
    • aria-owns="idOfAutocompletionListWrapper"
  • Give the input field:
    • aria-autocomplete="list"
    • aria-controls="idOfAutocompletionListWrapper"
  • You should not need to change anything else that I did in timelion, since you already have a single row input (unfortunately you need to trick a bit if you want to use it for multiline inputs).
  • For you auto completion list:
    • role="listbox" on the list wrapping element
    • role="option" on the individual suggestions
    • each suggestion need a unique id
    • (optional) an aria-label on the individual suggestions that should be read out to screen reader. By default the content will be used, and that should be fine (unless you figure out there is too much "noise" elements in it.
  • Now make the aria-activedescendant attribute on the input box always point to the id of the currently focused suggestion.

If you come into troubles implementing or testing, please feel free to ping me, we can also setup some pair programming to solve that.

@Bargs
Copy link
Contributor

Bargs commented Jul 9, 2018

Thanks Tim, I'll give this another shot with your advice

@Bargs
Copy link
Contributor

Bargs commented Jul 12, 2018

Thanks Tim for the help, you're a boss. I did exactly what you said and it worked first try. Here's the PR #20740

Bargs added a commit that referenced this issue Aug 9, 2018
Fixes #20099

I made the changes described by Tim at #20099 and everything seems to be working. I tried to update the typeahead in such a way that it can be made accessible anywhere it is used, even if there are multiple typeahead instances on a single page.

> (optional) an aria-label on the individual suggestions that should be read out to screen reader. By default the content will be used, and that should be fine (unless you figure out there is too much "noise" elements in it.

I did not do this bit since the text that is read seems reasonable to me, but I'm open to changing it if others feel differently.
Bargs added a commit to Bargs/kibana that referenced this issue Aug 9, 2018
Fixes elastic#20099

I made the changes described by Tim at elastic#20099 and everything seems to be working. I tried to update the typeahead in such a way that it can be made accessible anywhere it is used, even if there are multiple typeahead instances on a single page.

> (optional) an aria-label on the individual suggestions that should be read out to screen reader. By default the content will be used, and that should be fine (unless you figure out there is too much "noise" elements in it.

I did not do this bit since the text that is read seems reasonable to me, but I'm open to changing it if others feel differently.
Bargs added a commit that referenced this issue Aug 9, 2018
Fixes #20099

I made the changes described by Tim at #20099 and everything seems to be working. I tried to update the typeahead in such a way that it can be made accessible anywhere it is used, even if there are multiple typeahead instances on a single page.

> (optional) an aria-label on the individual suggestions that should be read out to screen reader. By default the content will be used, and that should be fine (unless you figure out there is too much "noise" elements in it.

I did not do this bit since the text that is read seems reasonable to me, but I'm open to changing it if others feel differently.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Project:Accessibility Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. WCAG A
Projects
None yet
Development

No branches or pull requests

3 participants