Aria issues

[viotopo]

I am having to issues validating the code and I don't know how to do it with choices.

1. ARIA items do not have accessible names

2. Elements with an ARIA [role] that require children to contain a specific [role] are missing some or all of those required children

Anybody knows how I can implement this on choices?

[Greg-Boggs]

Forgive me. I have replicated the errors using Axe scanner on the demo. If you scan the demo you'll see the WCAG 2.0 AA aria violations.

https://choices-js.github.io/Choices/

https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd

[seredniy]

Hey all!

Any news here?

[Xon]

The v11.0.x updates did see some aria related changes but it isn't completely fixed. Should be better than it used to be.

[mlinnetz]

Additionally, if we're entertaining minor a11y changes, a typical Choices dropdown will add the attribute
role="textbox"
to the search textbox:
<input type="search" class="choices__input" role="textbox" >

According to a11y best practice, it's recommended to not add the role="textbox" to an text or search element . Rather, screen readers and other assistive technologies already infer that it's a textbox from the element itself.

P.S. Thanks to the collaborators. Choices.js is a great plugin.

[Xon]

That should be a simple PR (looks to be just one spot adding the html attribute, and then updating a unit-test). Failing that can you link to the relevant a11y best practice so the change could be documented?

[mlinnetz]

That should be a simple PR (looks to be just one spot adding the html attribute, and then updating a unit-test). Failing that can you link to the relevant a11y best practice so the change could be documented?

I believe this is the precise link on the w3C aria documentation:
https://www.w3.org/TR/wai-aria-1.2/#textbox
and the relevant passage is:

The intended use is for languages that do not have a text input element, or cases in which an element with different semantics is repurposed as a text field.

Additionally, I find the Mozilla MDN documentation to be helpful: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/textbox_role

The textbox role is used to identify an element that allows the input of free-form text. Whenever possible, rather than using this role, use an element with type="text", for single-line input, or a <textarea> element for multi-line input.

In other words, both sources imply this should only be used on non-input elements.

We'd run an accessibility scan against our site, and it did in fact trigger a "attribute is not allowed" error.

I just submitted a PR, please review, much appreciated.
I did run a quick test locally, and while i can't run the same a11y scan to confirm that the warning is gone, I can report that the choices dropdown and search box worked just fine without the role attribute.

[Xon]

@mlinnetz that has been merged in. I don't have an ETA for the next release but the minified js files have also been updated if you require those, otherwise just building against main branch should work