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
Accessibility issues in Select2 #3744
Comments
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
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.
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
/cc @okonomiyaki |
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! |
@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. |
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! |
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: The Wave Toolbar highlights a bunch of issues that can be tackled: Tenon.io highlights a few more: 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: |
Select2 currently does not have a rigid release schedule, though this is the current one I have marked down.
Which should put Select2 4.0.2 in the range of Wordpress 4.4, depending on when there is a code/feature freeze.
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.
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.
|
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). The Government of Canada had this example as part of their toolset (it's been well tested): 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. |
FYI: Graham Armfield tested with Dragon NaturallySpeaking |
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! |
It would be fantastic if select2 gets more accessible. Thanks a lot for your work! |
Any news on the progress of this? |
Also hoping for a program update, here. Thanks! |
👍 |
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 ... |
Looking just at the "Single select boxes" example. the |
Dropping a note just to see if we still have eyes on this |
Just peeking in to see if there are any updates on this issue. |
What is the current status of this? |
I assume that nobody has put any time into developing this in the last year. |
Given no replies to the 4 previous status update requests, my guess is no :( |
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. |
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. |
@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? |
@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. |
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 |
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. |
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. |
The day has finally come, you can follow the pull request at #5842 where we add an actual 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 |
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:
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. |
Hi any update on these accessibility issues for select2? |
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. |
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.
|
Hi, Now, I have all above mentioned issues with my screen reader while choosing/finding an item in a dropdown list. |
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 |
Hello is there an update on this? |
1 similar comment
Hello is there an update on this? |
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. |
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!
The text was updated successfully, but these errors were encountered: