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

Stories/af/fix main aria roles properties #4348

Open
wants to merge 4 commits into
from

Conversation

Projects
None yet
3 participants
@afercia

afercia commented May 10, 2016

This pull request includes a

  • Bug fix
  • New feature
  • Translation

The following changes were made

  • fixes ARIA roles for the selection element and the search field
  • fixes ARIA roles for the results list
  • fixes ARIA properties aria-owns, aria-activedescendant, and aria-autocomplete
  • fixes ARIA role for the aria-live message

If this is related to an existing ticket, include a link to it as well.
See #3735

As mentioned in #3735 making the dropdown options being announced by screen reader will require several steps. Will comment with more details on the issue.

@@ -9,9 +9,9 @@ define([
var $search = $(
'<span class="select2-search select2-search--dropdown">' +
'<input class="select2-search__field" type="search" tabindex="-1"' +
'<input class="select2-search__field" type="text" tabindex="-1"' +

This comment has been minimized.

@kevin-brown

kevin-brown May 10, 2016

Member

The rest of the changes make sense, but I can't figure out why this change was needed. Can a search field not function as a combobox?

@kevin-brown

kevin-brown May 10, 2016

Member

The rest of the changes make sense, but I can't figure out why this change was needed. Can a search field not function as a combobox?

This comment has been minimized.

@afercia

afercia May 11, 2016

Well, the semantics of this input field is completely overridden by the applied ARIA role. Technologies that understand ARIA will get it is a "combobox" (also, currently has a role="textbox") so the type attribute is not so much relevant.
About browsers, the only difference with a text box I'm aware of is webkit special styling which Select2 resets with CSS

@afercia

afercia May 11, 2016

Well, the semantics of this input field is completely overridden by the applied ARIA role. Technologies that understand ARIA will get it is a "combobox" (also, currently has a role="textbox") so the type attribute is not so much relevant.
About browsers, the only difference with a text box I'm aware of is webkit special styling which Select2 resets with CSS

@@ -14,7 +14,7 @@ define([
Results.prototype.render = function () {
var $results = $(
'<ul class="select2-results__options" role="tree"></ul>'
'<ul class="select2-results__options" role="listbox"></ul>'

This comment has been minimized.

@kevin-brown

kevin-brown May 10, 2016

Member

How well does this work with a nested group role?

Part of the reason why tree was picked was because it supported nesting of options. From what we could tell, listbox only supports a single level (completely flat).

@kevin-brown

kevin-brown May 10, 2016

Member

How well does this work with a nested group role?

Part of the reason why tree was picked was because it supported nesting of options. From what we could tell, listbox only supports a single level (completely flat).

This comment has been minimized.

@afercia

afercia May 11, 2016

A "tree" widget is something different, from the spec:

A type of list that may contain sub-level nested groups that can be collapsed and expanded
The ARIA authoring practices describe the interaction screen readers should implement with ARIA widgets, I think using a Tree View is one of the main reasons the Select2 options are not announced. See version 1.0 and 1.1 (both working drafts):
https://www.w3.org/TR/wai-aria-practices/#TreeView
https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView

On the other hand, the Combobox widget explicitly requires a listbox with options, see:
https://www.w3.org/TR/wai-aria-practices/#combobox
https://www.w3.org/TR/wai-aria-practices-1.1/#combobox

I'm afraid ARIA doesn't provide a way to emulate the semantics of optgroup or at least I wasn't able to find it. Nested groups would require further investigation and iteration. That's why I'm proposing to proceed with small steps and then iterate, if you agree :)

Testing the PR, only Firefox+NVDA announce the group "labels", IE11+JAWS skip the labels but do announce the options, Safari+VoiceOver announce just the "flat" ones.

@afercia

afercia May 11, 2016

A "tree" widget is something different, from the spec:

A type of list that may contain sub-level nested groups that can be collapsed and expanded
The ARIA authoring practices describe the interaction screen readers should implement with ARIA widgets, I think using a Tree View is one of the main reasons the Select2 options are not announced. See version 1.0 and 1.1 (both working drafts):
https://www.w3.org/TR/wai-aria-practices/#TreeView
https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView

On the other hand, the Combobox widget explicitly requires a listbox with options, see:
https://www.w3.org/TR/wai-aria-practices/#combobox
https://www.w3.org/TR/wai-aria-practices-1.1/#combobox

I'm afraid ARIA doesn't provide a way to emulate the semantics of optgroup or at least I wasn't able to find it. Nested groups would require further investigation and iteration. That's why I'm proposing to proceed with small steps and then iterate, if you agree :)

Testing the PR, only Firefox+NVDA announce the group "labels", IE11+JAWS skip the labels but do announce the options, Safari+VoiceOver announce just the "flat" ones.

@kevin-brown kevin-brown added the 4.x label May 10, 2016

@kevin-brown

This comment has been minimized.

Show comment
Hide comment
@kevin-brown

kevin-brown Sep 10, 2016

Member

I want to thank Paal Joachim Romdahl for reminding me about this pull request, not because I forgot about it (I've been discussing this with a few others for a while now), but because I never publicly commented about the plans for Select2 to handle this.


As has been mentioned a couple of times before, Select2 supports a wide variety of use cases, some of which are natively supported by screen readers and others not so much. Our goal with Select2 4.0.0 was to make Select2 natively accessible and to do it right the first time, so we didn't have to hack it in later. Part of that involved researching existing implementations, looking into any recent improvements to ARIA, and doing some testing of our own along the way. As we've clearly learned after the release of Select2 4.0.0, we didn't get it right the first time, we actually got it very wrong. We accept that, and hopefully we can get Select2 to a state where it is at least partially acceptable, so the most basic use cases work natively. From there, we hope to work to get the more advanced use cases supported.

In the next couple of weeks, we plan to work with others to get Select2 to be accessible under the most basic use case: a flat dropdown that is searchable. Since that appears to be the use case that most screen readers support.

Member

kevin-brown commented Sep 10, 2016

I want to thank Paal Joachim Romdahl for reminding me about this pull request, not because I forgot about it (I've been discussing this with a few others for a while now), but because I never publicly commented about the plans for Select2 to handle this.


As has been mentioned a couple of times before, Select2 supports a wide variety of use cases, some of which are natively supported by screen readers and others not so much. Our goal with Select2 4.0.0 was to make Select2 natively accessible and to do it right the first time, so we didn't have to hack it in later. Part of that involved researching existing implementations, looking into any recent improvements to ARIA, and doing some testing of our own along the way. As we've clearly learned after the release of Select2 4.0.0, we didn't get it right the first time, we actually got it very wrong. We accept that, and hopefully we can get Select2 to a state where it is at least partially acceptable, so the most basic use cases work natively. From there, we hope to work to get the more advanced use cases supported.

In the next couple of weeks, we plan to work with others to get Select2 to be accessible under the most basic use case: a flat dropdown that is searchable. Since that appears to be the use case that most screen readers support.

@michalkleiner

This comment has been minimized.

Show comment
Hide comment
@michalkleiner

michalkleiner Apr 24, 2017

Contributor

Related PR #4881.

Contributor

michalkleiner commented Apr 24, 2017

Related PR #4881.

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