Skip to content
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

Set the main ARIA 1.1 roles and properties for comboboxes #5582

Merged
merged 6 commits into from Jul 30, 2019
Merged

Conversation

kevin-brown
Copy link
Member

@kevin-brown kevin-brown commented Jul 21, 2019

This pull request includes a

  • Bug fix
  • New feature
  • Translation

The following changes were made

  • Move accessibility tests for selections in with the other tests for selections
  • Set aria-owns and aria-activedescendent for the search box in selections

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

One small piece of #3735.
The code here is heavily based on #4348 but is updated for the changes that have been made over the years.

@kevin-brown kevin-brown added this to the 4.0.9 milestone Jul 21, 2019
@kevin-brown kevin-brown changed the title Set the main ARIA roles and properties Set the main ARIA 1.2 roles and properties for comboboxes Jul 27, 2019
@kevin-brown kevin-brown changed the title Set the main ARIA 1.2 roles and properties for comboboxes Set the main ARIA 1.1 roles and properties for comboboxes Jul 27, 2019
kevin-brown and others added 6 commits July 29, 2019 22:28
This is a reduced version of a5ab08b which is split out to only
set the `aria-activedescendent` and `aria-owns` attributes on the
search box located within the selection container. This is the search
box used within a multiple select, and previously it did not always
set these two attributes correctly.

One major change here is that we clear the `aria-activedescendent`
attribute if the result that is selected does not have an ID. This
was not being done previously, instead the attribute was still
containing the old value, and it meant that sometimes the wrong
result was being pointed to.

The test coverage for this was also expanded to ensure that these
attributes are properly being set.
This is a reduced version of a5ab08b which is split out to only
set the `aria-activedescendent` and `aria-owns` attributes on the
search box located within the dropdown. This is the search box used
within a single select, and previously it did not set these two
attributes at all. Additionally, it did not set the `aria-autocomplete`
attribute, which is also needed for screen readers to properly read
through the list of results.

There was previously no test coverage for this, so the tests were
largely copied from the tests for selection search.
When Select2 4.0.0 was originally written, accessibility was tested
using the Orca screen reader and Mozilla Firefox as the browser.
Because a `<select>` box could contain `<optgroup>` elements, which
can further contain additional `<option>` elements, Orca would read
out a `<select>` box as a tree view. Apparently Orca was the only
screen reader to do this, but Select2 maintained this behaviour
because the ARIA spec did not allow grouping elements for the right
roles.

In the ARIA 1.2 spec, an element with the role of `listbox` (which
is the proper one for representing a `<select>` element) can now
contain elements with the role of `group` that can be used for
grouping. This means that now Select2 can switch to use the proper
ARIA roles to better match how most browsers represent the `<select>`
element out of the box.

As a result, instead of the Select2 results list being represented
as a tree containing tree items, it is now represented as a listbox
containing options and groups. Notices will be represented as an
alert, which more closely represents what they were being used for.

This is a reduced version of a5ab08b which is split out to only
fix the `role` attributes on elements within the results list.
I'm pretty sure this is implicit now, but since we used to specify
that the search box had a role of `textbox`, we may as well migrate
that over to specify the role of `searchbox`. This is different
from the original pull request where this role was changes to
`combobox`, but that is because we are working against the ARIA 1.2
spec and the original pull request was working agianst the ARIA 1.0
spec, which required the search box to have that role.
In ARIA 1.1, there was a switch to use `aria-controls` on the search
box to point to the results list instead of using `aria-owns`. This
is required because the `combobox`, in our case the selection
container, should have the `aria-owns` attribute pointing to the
results list. And because only one elment can own another element,
we must fall back to `aria-controls` to represent that relationship.

The tests have also been adjusted to reflect this new discovery.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants