Accessibility issues in Select2

[joedolson]

Hi! The WordPress accessibility team did some extensive testing of Select2 with an eye towards whether or not we could make use of it in the WordPress core. Unfortunately, we found a lot of issues that need to be addressed before it's a reasonable candidate for us. You can find the results of our user testing here: https://make.wordpress.org/accessibility/2015/09/07/accessibility-usertest-select2/

We'd love to work with you to resolve these issues - let us know what the best way for your workflow would be for us to move forward on this! Thank you!

[kevin-brown]

Let me start off by saying thank you for doing this, you linked to a pretty thorough write-up and it will definitely be useful when fixing the accessibility issues in Select2. I left a comment in a related ticket that I think is relevant to the current state of accessibility

Accessibility is important to us, but unfortunately it's something that we find difficult to test. During the creation of 4.0.0, we closely tested Select2 with GNOME's Orca to make sure it emulated the native select box as closely as possible.

If you could possibly give us some step-by-step instructions on how to test this issue with NVDA, that would be immensely helpful.

Now, I should mention that the accessibility being "difficult to test" for us doesn't mean that "we aren't interested" or "we would rather not doing it", but instead it's more of a training issue. We would love to make Select2 fully accessible, as our goal is to be a drop-in replacement, but we have no idea how to test it which makes it difficult.

We'd love to work with you to resolve these issues - let us know what the best way for your workflow would be for us to move forward on this!

As I've said before, I am definitely interested in getting these issues resolved. The next step moving forward would be to figure out the best place to centralize this discussion. With Select2, that usually happens either on GitHub or the mailing list, though I know that Wordpress has different channels and an open ticket about integrating Select2.

The next step would be to figure out what the really obvious accessibility issues in Select2 are and possible how they can be fixed. I noticed (based on a related ticket and the writeup) that the current focused option is not being read aloud in the autocomplete, and there was a mention that it could have something to do with a missing attribute for the active option. So I'll be looking into how that issue can be fixed in the near future.

I should mention that Select2 accepts pull requests through GitHub. I have plans in the next few days to update the contributing guide to address that process.

---

Related tickets

• options not read by screen readers
• Additional ARIA accessibility issues
• Make select2 accessible (add Aria roles)

/cc @okonomiyaki

[mgifford]

Thanks for this @joedolson Select2 has a lot of fans in the Drupal world too and we'd love to see it in Core. https://www.drupal.org/node/2346973

Thanks for publishing your results!

[helen]

@kevin-brown Thanks for your fast and friendly response - as I mentioned last year, we'd really love to be able to incorporate Select2 into WordPress because of both the functionality and the ease of working with you as a project. We've built up a solid accessibility team with a robust test group (as seen here), great leaders, and a number of very good developers. I'm hopeful that we'll be able to contribute upstream using your preferred workflow, along with any other interested developers (would love to collaborate with Drupal here!), and we can leave the WordPress Trac ticket just for our own tracking of the general movement and what we need to do on our end for integration.

The only thing I would note is that we operate on a fairly regular rapid release schedule without much, if any, flex in the release date. We're still finalizing the release date for 4.4 (our third and last release for the year), but I imagine it'll be mid-December or slightly before. I'm not sure what your typical release cycle/process looks like, so if that's something we should talk about a bit more, please do let me know.

[joedolson]

Thanks for your reply, @kevin-brown!

First, from a workflow perspective, we're happy to make pull requests, but we also feel that providing advice and support to help people more intimately familiar with the codebase make the needed changes might be more efficient - it's fairly safe to assume that you know the Select2 code much better than we do! A mix of issues, advice, and PRs might be the way to go. We can feel this out as we go along, I imagine.

Second, testing in a screen reader. It's not as hard as it might seem, at least at a non-expert level. NVDA is a free, open-source screen reader, so you can download and install it at any time. There's a great article from WebAIM about using NVDA to do accessibility testing, which gives an introduction to the most important navigation shortcuts and commands and how they work.

http://webaim.org/articles/nvda/

There's also an equivalent article for VoiceOver on Mac: http://webaim.org/articles/voiceover/

Since a license for Jaws is quite expensive, we'll have our expert testers do testing in that environment.

One of the things that we can definitely provide is our testing community - we're happy to take iterations of Select2 and have our testers try them out and see how they work.

Thank you!

[mgifford]

Those are definitely good links from @joedolson but there's a lot that can be done before getting to screen reader testing.

It would be useful to start with the example page posted here:
https://select2.github.io/examples.html

The Wave Toolbar highlights a bunch of issues that can be tackled:
http://wave.webaim.org/report#/https%3A%2F%2Fselect2.github.io%2Fexamples.html

Tenon.io highlights a few more:
http://tenon.io/testNow.php?url=https://select2.github.io/examples.html

This is just an easier start than learning how to use a screen reader. But if you clear out the low hanging fruit and those issues which are already identified by the WP evaluation you'll be much further ahead. If the example page is cleaned up, you can ask for users with disabilities who actually use these Assistive Technologies to give you feedback.

I like Denis' approach when looking at NVDA testing:
http://denisboudreau.org/presentations/2015/a11yYOW/GAAD2015-nvda-a11y-testing-dboudreau-final.pdf

[kevin-brown]

I'm not sure what your typical release cycle/process looks like, so if that's something we should talk about a bit more, please do let me know.

Select2 currently does not have a rigid release schedule, though this is the current one I have marked down.

• Sept. 13th - 4.0.1-rc.1
• Sept. 20th - 4.0.1-rc.2
• Sept. 27th - 4.0.1
• Oct. 24th - 4.0.2-rc.1
• Oct. 31st - 4.0.2-rc.2
• Nov. 7th - 4.0.2

Which should put Select2 4.0.2 in the range of Wordpress 4.4, depending on when there is a code/feature freeze.

A mix of issues, advice, and PRs might be the way to go.

I definitely agree. While I enjoy PRs, as they provide quick one-time fixes, providing advice tends to have a much greater impact and will allow us to understand why changes need to be made. As they always say, "give a man a fish..."

I should also mention that we prefer smaller, more targeted tickets over broad ones as they allow us to better track the progress that is being made. This ticket will likely turn into the general tracking ticket for accessibility issues once we identify the specific changes that need to be made.

It would be useful to start with the example page posted here

The examples page is something that we're in the process of improving, so we should definitely be able to improve the accessibility there in the near future.

---

I do have a few more specific questions based on the review that was originally linked.

1. What key bindings are typically used for opening or closing the dropdown?

   There were some comments about hitting the space bar to open it, but we also support alt + down (General binding). Ctrl + option + space was also mentioned as a non-functioning binding, though I'm not sure what key event that was supposed to simulate.

   The comment about using the down arrow is related to Arrow keys do not change value of select #3472, it doesn't appear to be a consistent binding from testing that has been done.

2. What is the recommended markup for handling multiple selections?

   I was able to find plenty of resources in the past for accessible dropdowns, but next to none for dropdowns which support multiple options. As noted in the review, Select2 does a poor job of indicating what options are selected when working with multiple selections, and this is part of the reason.

[mgifford]

Thanks @kevin-brown I don't have any specifics to offer to you, but there are some examples of similar tools. jQuery-UI's autocomplete has been a good example (if a bit limited).
http://jqueryui.com/autocomplete/

The Government of Canada had this example as part of their toolset (it's been well tested):
https://wet-boew.github.io/wet-boew/demos/datalist/datalist-dynamic-en.html

You're definitely going to need to use ARIA well for your more complex examples.

Start with the low hanging fruit though and let's move up to the more complex stuff.

Happy to hear that the example page is being improved.

[rianrietveld]

FYI: Graham Armfield tested with Dragon NaturallySpeaking
https://make.wordpress.org/accessibility/2015/09/07/accessibility-usertest-select2/#comment-72524

[joedolson]

Just to follow up; we're working on figuring out what issues to raise and resources we can provide to be most useful; it's unlikely we'll hit 4.0.1, but we'd definitely like to get some fixes into 4.0.2. Thanks!

[heebj]

It would be fantastic if select2 gets more accessible. Thanks a lot for your work!

[heebj]

Any news on the progress of this?

[jesconstantine]

Also hoping for a program update, here. Thanks!

[alexyorke]

👍

[binary-koan]

I've got a PR (which may not be completely working yet) open for #3735 and another couple of fixes which I'm trying to find time to test and submit. Not sure what the progress on any of the other issues is though ...

[afercia]

Looking just at the "Single select boxes" example. the aria-activedescendant attribute is set on the <span> with role combobox. By the way, when searching, the cursor is on the input field and browsers, as well as assistive technologies, focus on... the focused element :) Basically, aria-activedescendant should be used on the input field.
Sorry I can't do a PR, really haven't much time for this, but should be a pretty simple fix.

[evertiro]

Dropping a note just to see if we still have eyes on this

[jason-jason-h]

Just peeking in to see if there are any updates on this issue.

[andreafalzetti]

What is the current status of this?

[mgifford]

I assume that nobody has put any time into developing this in the last year.

[Neurrone]

Given no replies to the 4 previous status update requests, my guess is no :(

[drewB]

Don't know if this considered bad form on an open source project but but my company Waggl is willing to financially support working toward WCAG Level A compliance (we can't spare staff right now). If there is anyone who knows the code base well and is interested in doing this as a contract shoot me at note at batshaw+select2@waggl.com.

[claudiulodro]

https://github.com/woocommerce/selectwoo

We're currently working on a fork of select2 with improved accessibility. It should be ready in the near future.

[drewB]

@claudiulodro that is great to hear. Is there a reason you are creating it as a seperate library instead of doing it as a pull request into select2?

[claudiulodro]

@drewB I'd do it with PRs if I thought they would get merged in, but I doubt they will. There's been no action in this repo in about 6 months and the fork contains some PRs that have been waiting to get merged here for a very long time.

[andruhon]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I think it's still actual

[jensiegirl-devada]

Hi all 👋🏻

I am a new follower of this repository. I see that there hasn't been activity on this issue for a while, but I've tested this with multiple screen-readers, so I thought I might chime in.

The buttons on each tag that trigger the removal or deletion of a tag with the multi-select option are not accessible via the keyboard. This could be frustrating for users that rely on the keyboard and are unable to use a mouse.

I would suggest that the buttons be made tabbable and that each is labeled with "Remove [option text]" so that the buttons are accessible to both screen-reader users and users that cannot use a mouse.

This would mean that the fully-rendered markup might look something like this:

<span class="select2-selection select2-selection--multiple" role="combobox" aria-haspopup="true" aria-expanded="false" tabindex="-1">
  <ul class="select2-selection__rendered">
    <li class="select2-selection__choice" title="test text" data-select2-id="3"> . 
        <span class="select2-selection__choice__remove" aria-label="Remove test text"  role="button" tabindex="0"> <!-- this could also just be a button -->
        <span aria-hidden="true">×</span> <!-- we would want this to be hidden from screen readers as it is not meaningful to the user -->
        </span>
        test text
    </li>
    <li class="select2-search select2-search--inline">
       <input class="select2-search__field" type="search" tabindex="0" autocomplete="off" autocorrect="off" autocapitalize="none" spellcheck="false" role="textbox" aria-autocomplete="list" placeholder="" style="width: 0.75em;">
    </li>
  </ul>
</span>

This issue seems to have been mentioned in several PRs/Issues, but I don't know if anyone has started working on it or if there is a PR for it.

A link to a JSBin example where I looked at this issue may be found here: https://jsbin.com/tabusec/edit?html,output

Related Pull Request: #5571

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kevin-brown]

One of the near-term goals is to swap out the "x" that is present on options for a proper button with help text and keyboard accessibility. The timeline in my head is 4.1.0, which may be tricky knowing that it is going to have effects on themes.

[kevin-brown]

The day has finally come, you can follow the pull request at #5842 where we add an actual <button> for the "Remove all items" icon as well as the individual "Remove item" icons that have been present on the selected choices. We also removed the search input from the list of selections (as well as the clear button, but nobody noticed that) and added proper ARIA attributes to link things together.

While I understand that it has been a while, it would be greatly appreciated if anyone could help us test out these changes to ensure this ticket has been fixed. You can test these on your own by recompiling Select2 from the lastest develop branch, or you can wait for the next beta release (which should be out once that pull request is merged). Our goal is to significantly improve the accessibility in time for the upcoming 4.1.0 release of Select2.

[shawnmintz]

Hi @kevin-brown, Congratulations on the work that you have done to ensure Select2 works with screen readers. We have been testing with Jaws, ZoomText, TalkBack, and VoiceOver. Overall, everything is working very nicely. We are experiencing some issues with VoiceOver on an iPhone, though:

• Some drop-down menus aren't staying opened - they open for a second and then close.

• When using the up and down arrow on an iPhone to move to the previous or next field. For a couple of fields, the drown-down menus don't close as it advances to the next field. So basically, It's on another field, but the drop-down menu from the previous field is covering the field that I'm on.

Let me know if there are any workarounds and ideas that we can put into place to overcome these.

Thanks again. We are excited to deploy your latest version of Select2 shortly.

[jimbyo]

Hi any update on these accessibility issues for select2?

[alexjose]

Any update on this?

[kevin-brown]

Any update on this?

Forever a work in progress (accessibility never stops, there are always ways to improve), but at this point I need the assistance of y'all to identify the specific issues (bonus points for proposing fixes or working with me through testing).

It's been noted that 4.1.0 (not yet released but has release candidates) is an improvement over 4.0.x, but there's still more that can be improved.

[shawnmintz]

Hi @kevin-brown

Thank you for being open to more accessibility feedback. Here are some of our recent findings using JAWS (PC) or VoiceOver (Mac), amongst other similar tools.

1. Pills don't remove themselves atomically (both with and without tags enabled) when using the keyboard to edit the field (such as typing backspace in the "search" textfield).

2. There is no easy way to remove a selection using JAWS. UPDATE: We found a solution for this by using CTRL+space to add/remove selections. Is this the only work-around?

3. Existing selections don't announce themselves when a field is entered (it says only: "search edit, contains text"). UPDATE: We have fixed this by patching select2 to set the "aria-labelledby" attribute of the "search" textfield to the ID of the "container" element. This makes the screenreader announce the current selections.

4. The purpose or label of a field is not announced when a field is entered. UPDATE: We have fixed this by patching select2 to prepending the value of the "aria-labelledby" attribute with a label ID derived using the select2 standards - and adjusting our label IDs to match. This makes the screenreader announce the field purpose before the current selections are read (see above).

5. Attempting to walk off the top/bottom of the results list using the keyboard is not announced. Because of this, the user must infer that the lack of announcement is an indication, but this approach is sometimes flawed.

6. There is no (easy?) way to get the selections to announce themselves when returning to the field from the list. UPDATE: A poor workaround is to leave and re-enter the field.

7. When close-on-select is set to false, there is no visual way to close the popup list. Some users know to type ESC, but most do not. Most will attempt to click outside the list popup, which can be successful but occasionally triggers another screen element. We have received negative feedback about this on many occasions. We feel the addition of an "x" somewhere near the list would provide enough of a visual cue.

[cankirca]

Hi,
I'm a screen reader user. I'm using a php based software and it comes with Select2 4.0.5.
Plugins/Select2 folder contains JS and i18n folders and there is only select2.min.js.

Now, I have all above mentioned issues with my screen reader while choosing/finding an item in a dropdown list.
SO how can I apply above solutions to my file?
If I download select2.min.js file and replace it, will it be a solution?
Thank you.

[huinkerpaytonPFG]

The purpose or label of a field is not announced when a field is entered. UPDATE: We have fixed this by patching select2 to prepending the value of the "aria-labelledby" attribute with a label ID derived using the select2 standards - and adjusting our label IDs to match. This makes the screenreader announce the field purpose before the current selections are read (see above).

I feel like a may be missing something here. I pulled in the latest release 4.1.0-rc.0 to codepen and test with NVDA and there is nothing that labels the select2 single or multiple when focused. Based on the reply above it sounds like there was something done to mitigate this, but I have not been able to verify. Can someone elaborate?

What I do see happening is that the textbox for a single gets the aria-labelledBy="select2-id_label_single-2-container" which applies to the container, when it should really be tied to the original label <label for="id_label_single-2">. What might be throwing some devs off is that when a placeholder is applied it initially seems like there is a label, but once a value is selected that placeholder is no longer announced which renders the input inaccessible.

[matthewford]

Hello is there an update on this?

[dbuhonov]

Hello is there an update on this?

[joshmrallen]

Hello is there an update on this?

For anyone else tracking this issue, I've seen people moving to selectize which provides some useful plugins and properties that make it possible to add accessibility and keyboard navigation.