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

Make select2 accessible (add Aria roles) #2499

Closed
koleary opened this Issue Jun 27, 2014 · 22 comments

Comments

Projects
None yet
4 participants
@koleary

koleary commented Jun 27, 2014

There is an issue in the Drupal 8 queue to add chosen to Drupal core and select2 was proposed as an alternative. The blocker to both of these libraries is that they are not accessible.

There is a really good example of how this can be done here:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Here's the javascript: http://cookiecrook.com/test/aria/multiselect/js/aria.js

This maps closely to the basic select functionality. It looks pretty simple to implement using the listbox and multiselectable Aria properties
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria-multiselectable

I would make a patch myself but I'm not so hot at js.

@koleary koleary changed the title from Mak select2 accessible to Make select2 accessible (add Aria roles) Jun 27, 2014

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Jun 27, 2014

Member

Can you link us to the Drupal 8 issue?

In the last few releases, we made quite a few fixes for accessibility and haven't heard much since, so it would be useful to get some more specific feedback about what is required.

Member

kevin-brown commented Jun 27, 2014

Can you link us to the Drupal 8 issue?

In the last few releases, we made quite a few fixes for accessibility and haven't heard much since, so it would be useful to get some more specific feedback about what is required.

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary commented Jun 27, 2014

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Jun 27, 2014

Also, the issue I am working on in which I propose this interaction pattern
is here: https://www.drupal.org/node/2284687#comment-8921657

koleary commented Jun 27, 2014

Also, the issue I am working on in which I propose this interaction pattern
is here: https://www.drupal.org/node/2284687#comment-8921657

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Jul 1, 2014

Contributor

Would be great to make this more accessible. ARIA would be a great start. There are already some here in the example http://ivaynberg.github.io/select2/

The example page is missing basic stuff like labels, but that shouldn't be a problem in Drupal. Just makes it harder to evaluate Select2

Contributor

mgifford commented Jul 1, 2014

Would be great to make this more accessible. ARIA would be a great start. There are already some here in the example http://ivaynberg.github.io/select2/

The example page is missing basic stuff like labels, but that shouldn't be a problem in Drupal. Just makes it harder to evaluate Select2

@kevin-brown kevin-brown self-assigned this Jul 1, 2014

@kevin-brown kevin-brown added this to the 3.5.1 milestone Jul 1, 2014

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Jul 1, 2014

So I dug in a little deeper here and I realized that the example I provided above does NOT solve the problem. I also noticed that the listbox, tabindex, and labelledby appear to be used correctly.

The things that need to be done are (in order of importance).
-Add role to options (role="option")
-Add selected attribute (aria-selected="false", aria-selected="true") to options
-Sub-list labels need to be screen-readable (eg. "Pacific time zone" in the example) are not read by the screen reader. Not sure how to fix that.

Right now you can use the arrow keys to go back through the selected options and the delete key to remove them but the screen reader doesn't tell you what they are or how to remove them.

koleary commented Jul 1, 2014

So I dug in a little deeper here and I realized that the example I provided above does NOT solve the problem. I also noticed that the listbox, tabindex, and labelledby appear to be used correctly.

The things that need to be done are (in order of importance).
-Add role to options (role="option")
-Add selected attribute (aria-selected="false", aria-selected="true") to options
-Sub-list labels need to be screen-readable (eg. "Pacific time zone" in the example) are not read by the screen reader. Not sure how to fix that.

Right now you can use the arrow keys to go back through the selected options and the delete key to remove them but the screen reader doesn't tell you what they are or how to remove them.

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Jul 1, 2014

Member

The PRs where improved support was added: #1816 #1885

Add role to options (role="option")

The option labels have role="option" set already (ref), does this need to be changed at all?

Add selected attribute (aria-selected="false", aria-selected="true") to options

Does this apply to options which are not visible (the case for multiple select options)?

Sub-list labels need to be screen-readable (eg. "Pacific time zone" in the example) are not read by the screen reader. Not sure how to fix that.

As you've likely noticed, the labels are not selectable. Because of this, they are not presented to screen readers as possible options. I'm not sure what the best way to fix this would be so they are read.


Unfortunately I have no idea how to correctly test accessibility issues, so there is only so much that I can do to improve this. Pull requests are welcome though, as we are always interested in improving the accessibility of Select2.

Member

kevin-brown commented Jul 1, 2014

The PRs where improved support was added: #1816 #1885

Add role to options (role="option")

The option labels have role="option" set already (ref), does this need to be changed at all?

Add selected attribute (aria-selected="false", aria-selected="true") to options

Does this apply to options which are not visible (the case for multiple select options)?

Sub-list labels need to be screen-readable (eg. "Pacific time zone" in the example) are not read by the screen reader. Not sure how to fix that.

As you've likely noticed, the labels are not selectable. Because of this, they are not presented to screen readers as possible options. I'm not sure what the best way to fix this would be so they are read.


Unfortunately I have no idea how to correctly test accessibility issues, so there is only so much that I can do to improve this. Pull requests are welcome though, as we are always interested in improving the accessibility of Select2.

@kevin-brown kevin-brown removed their assignment Jul 1, 2014

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Jul 2, 2014

Oh, excellent. Maybe I'm not seeing it because I am testing against the demo? I'll pull and test locally.

As far as testing a11y, I'm on a mac and I just use the built in screen reader (system preferences/accessibility/voice over/enable voice over [checkbox]. Then I just tab around with my eyes closed and see what I can and can't do. :)

I think only the selected (visible) options need the aria-selected="true". The screen reader reads the others just fine, it just doesn't read the selected ones or let you know that they can be deselected by using the delete key (I believe this is the default behavior for an aria-selected="true" element).

As for the sub-item lists I think that giving them an ID and referencing that in the UL with the "labelledby" attribute plus the ID is how that's done but I'm not 100% sure.

koleary commented Jul 2, 2014

Oh, excellent. Maybe I'm not seeing it because I am testing against the demo? I'll pull and test locally.

As far as testing a11y, I'm on a mac and I just use the built in screen reader (system preferences/accessibility/voice over/enable voice over [checkbox]. Then I just tab around with my eyes closed and see what I can and can't do. :)

I think only the selected (visible) options need the aria-selected="true". The screen reader reads the others just fine, it just doesn't read the selected ones or let you know that they can be deselected by using the delete key (I believe this is the default behavior for an aria-selected="true" element).

As for the sub-item lists I think that giving them an ID and referencing that in the UL with the "labelledby" attribute plus the ID is how that's done but I'm not 100% sure.

@kevin-brown kevin-brown modified the milestones: 3.5.2, 3.5.1 Jul 22, 2014

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Jul 24, 2014

Contributor

ARIA can definitely be useful to make interactive forms more accessible to screen readers. VoiceOver is a good way to test as is ChromeVox. For Windows users there is also NVDA which is a great screen reader that is on an open source license.

Also, it's good to put out a call for screen reader users who are interested in testing your library. Lots of options.

Contributor

mgifford commented Jul 24, 2014

ARIA can definitely be useful to make interactive forms more accessible to screen readers. VoiceOver is a good way to test as is ChromeVox. For Windows users there is also NVDA which is a great screen reader that is on an open source license.

Also, it's good to put out a call for screen reader users who are interested in testing your library. Lots of options.

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Jul 24, 2014

Contributor

Also, why isn't access http://ivaynberg.github.io/select2/index.html included as an example in the library? I was going to try to improve the example and send along a pull request, but there wasn't an index.html with your various examples included.

Part of the accessibility problem may be tied to the example HTML provided more than the JS library.

Contributor

mgifford commented Jul 24, 2014

Also, why isn't access http://ivaynberg.github.io/select2/index.html included as an example in the library? I was going to try to improve the example and send along a pull request, but there wasn't an index.html with your various examples included.

Part of the accessibility problem may be tied to the example HTML provided more than the JS library.

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Jul 24, 2014

Member

@mgifford Select2's documentation is served through GitHub Pages which uses the gh-pages branch of the repository.

Member

kevin-brown commented Jul 24, 2014

@mgifford Select2's documentation is served through GitHub Pages which uses the gh-pages branch of the repository.

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Jul 24, 2014

"Part of the accessibility problem may be tied to the example HTML provided more than the JS library."

Good point. I have only reviewed the examples and not cloned the repo. If the a11y bugs are an artifact of outdated examples and the bugs have been fixed upstream that would be awesome.

koleary commented Jul 24, 2014

"Part of the accessibility problem may be tied to the example HTML provided more than the JS library."

Good point. I have only reviewed the examples and not cloned the repo. If the a11y bugs are an artifact of outdated examples and the bugs have been fixed upstream that would be awesome.

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Jul 24, 2014

Contributor

I created this pull request #2560

this just eliminates the low hanging fruit. More testing would be necessary to find other a11y bugs. But still useful to do.

This probably has formatting issues.. But, ya, I didn't concern myself with that.

Contributor

mgifford commented Jul 24, 2014

I created this pull request #2560

this just eliminates the low hanging fruit. More testing would be necessary to find other a11y bugs. But still useful to do.

This probably has formatting issues.. But, ya, I didn't concern myself with that.

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Jul 30, 2014

Hi,

I just updated the issue on Drupal.org to add Select2 with this comparison
spreadsheet.

You guys come out looking pretty good :)

https://docs.google.com/spreadsheets/d/1vifOGL_4wgOl6sy2Os59k24saIHvwFFQoi5brH5Uv28/view

Feel free to correct any inaccuracies and use this in your own
documentation. I will continue to push hard on getting this in to Drupal 8
core notwithstanding the remaining a11y gaps.

The remaining a11y stuff that I think would be most helpful would be adding
aria-multiselectable and aria-selected (or possibly aria-checked?)
attributes where appropriate. That would cover the biggest issue which is
that the selected pills are not read out when tabbed over.

Next after that would be adding aria-valuemax and valuemin where minimum
and maximum values are used, and adding aria-disabled for disabled values
and aria-readonly for locked values.

Thanks!

koleary commented Jul 30, 2014

Hi,

I just updated the issue on Drupal.org to add Select2 with this comparison
spreadsheet.

You guys come out looking pretty good :)

https://docs.google.com/spreadsheets/d/1vifOGL_4wgOl6sy2Os59k24saIHvwFFQoi5brH5Uv28/view

Feel free to correct any inaccuracies and use this in your own
documentation. I will continue to push hard on getting this in to Drupal 8
core notwithstanding the remaining a11y gaps.

The remaining a11y stuff that I think would be most helpful would be adding
aria-multiselectable and aria-selected (or possibly aria-checked?)
attributes where appropriate. That would cover the biggest issue which is
that the selected pills are not read out when tabbed over.

Next after that would be adding aria-valuemax and valuemin where minimum
and maximum values are used, and adding aria-disabled for disabled values
and aria-readonly for locked values.

Thanks!

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Jul 30, 2014

One more thing.

Just remembered you have draggable options.

Those will need: aria-dropeffect and aria-grabbed (state)

thx!

koleary commented Jul 30, 2014

One more thing.

Just remembered you have draggable options.

Those will need: aria-dropeffect and aria-grabbed (state)

thx!

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Jul 30, 2014

Member

Feel free to correct any inaccuracies and use this in your own documentation.

  • Disable search for n values - Supported with the minimumResultsForSearch option
  • No results message - Supported with the formatNoMatches option
  • Maximum options - Supported with the maximumSelectionSize option
Member

kevin-brown commented Jul 30, 2014

Feel free to correct any inaccuracies and use this in your own documentation.

  • Disable search for n values - Supported with the minimumResultsForSearch option
  • No results message - Supported with the formatNoMatches option
  • Maximum options - Supported with the maximumSelectionSize option
@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary commented Jul 30, 2014

Awesome!

@evgeny-o

This comment has been minimized.

Show comment
Hide comment
@evgeny-o

evgeny-o Aug 14, 2014

Hi,

I've encountered with a problem to relate dropdown list (created with select2) to its label.
Could anybody to assist me implement the following select2-component accessible behaviour: on tab press the focus should move to the dropdown component (from the previous component) and I should listen the component type(combobox), name (its label) and then current value (its selection). I'm using JAWS for validation.

Thanks an advance

evgeny-o commented Aug 14, 2014

Hi,

I've encountered with a problem to relate dropdown list (created with select2) to its label.
Could anybody to assist me implement the following select2-component accessible behaviour: on tab press the focus should move to the dropdown component (from the previous component) and I should listen the component type(combobox), name (its label) and then current value (its selection). I'm using JAWS for validation.

Thanks an advance

@koleary

This comment has been minimized.

Show comment
Hide comment
@koleary

koleary Aug 14, 2014

I can't tell you how to implement but I believe that the aria role:
tabindex is where you should be looking.

Here is the relevant documentation:
http://www.w3.org/TR/wai-aria/usage#managingfocus

and more specifically:
http://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#focus_tabindex

On Thu, Aug 14, 2014 at 4:37 AM, Evgeny notifications@github.com wrote:

Hi,

I've encountered with a problem to relate dropdown list (created with
select2) to its label.
Could anybody to assist me implement the following select2-component
accessible behaviour: on tab press the focus should move to the dropdown
component (from the previous component) and I should listen the component
type(combobox), name (its label) and then current value (its selection).
I'm using JAWS for validation.

Thanks an advance


Reply to this email directly or view it on GitHub
#2499 (comment).

Kevin O’leary | Director of design, Office of the CTO * | *Acquia

O: +1 (781) 238-8600 | M: +1 (781) 413-6016
E: kevin.oleary@acquia.com | Skype: tkoleary1
W: http://www.acquia.com

*Address: *25 Corporate Drive 4th Floor, Burlington, MA 01803

koleary commented Aug 14, 2014

I can't tell you how to implement but I believe that the aria role:
tabindex is where you should be looking.

Here is the relevant documentation:
http://www.w3.org/TR/wai-aria/usage#managingfocus

and more specifically:
http://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#focus_tabindex

On Thu, Aug 14, 2014 at 4:37 AM, Evgeny notifications@github.com wrote:

Hi,

I've encountered with a problem to relate dropdown list (created with
select2) to its label.
Could anybody to assist me implement the following select2-component
accessible behaviour: on tab press the focus should move to the dropdown
component (from the previous component) and I should listen the component
type(combobox), name (its label) and then current value (its selection).
I'm using JAWS for validation.

Thanks an advance


Reply to this email directly or view it on GitHub
#2499 (comment).

Kevin O’leary | Director of design, Office of the CTO * | *Acquia

O: +1 (781) 238-8600 | M: +1 (781) 413-6016
E: kevin.oleary@acquia.com | Skype: tkoleary1
W: http://www.acquia.com

*Address: *25 Corporate Drive 4th Floor, Burlington, MA 01803

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Sep 30, 2014

Contributor

Really interesting implementation by @nod_ in Drupal 8:
https://www.drupal.org/node/2346973

I've got lots of screenshots of how VoiceOver interacts with Select2 in two different instances.

I don't know which of the problems is caused by Select2 and which by Drupal 8, but worth looking at for folks who want to improve accessibility with this code.

Contributor

mgifford commented Sep 30, 2014

Really interesting implementation by @nod_ in Drupal 8:
https://www.drupal.org/node/2346973

I've got lots of screenshots of how VoiceOver interacts with Select2 in two different instances.

I don't know which of the problems is caused by Select2 and which by Drupal 8, but worth looking at for folks who want to improve accessibility with this code.

@kevin-brown kevin-brown referenced this issue Oct 15, 2014

Merged

Select2 4.0 #2743

82 of 82 tasks complete

@kevin-brown kevin-brown modified the milestone: 3.5.2 Oct 31, 2014

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Dec 18, 2014

Member

With 4.0 coming up, we tried to make it match the native <select> as much as possible. Unfortunately I have no idea how to thoroughly test it as I only have limited knowledge of how Orca works, but perhaps someone else can help with testing.

#2743

Member

kevin-brown commented Dec 18, 2014

With 4.0 coming up, we tried to make it match the native <select> as much as possible. Unfortunately I have no idea how to thoroughly test it as I only have limited knowledge of how Orca works, but perhaps someone else can help with testing.

#2743

@mgifford

This comment has been minimized.

Show comment
Hide comment
@mgifford

mgifford Jan 19, 2015

Contributor

Hey @kevin-brown - hope that 4.0 is coming along well.

I haven't actually used Orca. Android's TalkBack is also an option.

It's probably more useful though to see if you can get either of these working through Wine:
http://www.nvaccess.org/
http://www.chromevox.com/

Or just run them natively in Windows.

If this is a good time to test, do let us know. We can probably find someone to do some initial testing. Even just with http://wave.webaim.org/

Contributor

mgifford commented Jan 19, 2015

Hey @kevin-brown - hope that 4.0 is coming along well.

I haven't actually used Orca. Android's TalkBack is also an option.

It's probably more useful though to see if you can get either of these working through Wine:
http://www.nvaccess.org/
http://www.chromevox.com/

Or just run them natively in Windows.

If this is a good time to test, do let us know. We can probably find someone to do some initial testing. Even just with http://wave.webaim.org/

@kevin-brown kevin-brown added this to the 4.0 milestone Jan 19, 2015

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Feb 28, 2015

Member

Closing this off as I believe Select2 is now at a decent state for accessibility, where it is further ahead than Select2 3.5.x and more closely matches native implementations of a select box.

If there are any accessibility issues that are discovered in 4.0, feel free to create a new ticket or pull request and we can work them out.

Member

kevin-brown commented Feb 28, 2015

Closing this off as I believe Select2 is now at a decent state for accessibility, where it is further ahead than Select2 3.5.x and more closely matches native implementations of a select box.

If there are any accessibility issues that are discovered in 4.0, feel free to create a new ticket or pull request and we can work them out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment