* Move search accessibility tests under selection tests
* Set aria-activedescendent and aria-owns on selection search
This is a reduced version of a5ab08b49cb 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.
* Set aria-activedescendent and aria-owns on dropdown search
This is a reduced version of a5ab08b49cb 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.
* Set proper ARIA roles on result elements
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 a5ab08b49cb which is split out to only
fix the `role` attributes on elements within the results list.
* Switch search boxes to have a role of searchbox
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.
* Set aria-controls instead of aria-owns on search boxes
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.
This check is in place in most other places, mostly because we have
run into widespread issues under similar circumstances and we like to
avoid those, but it was forgotten here. There also were no tests
covering this, so it was never caught.
This adds tests that ensure that the option in the results list will
be generated with the correct "disabled" state based on whether or
not it, or a parent element, is marked as disabled.
This should have been easy: just check `element.disabled`
Unfortunately the `disabled` property is not inherited within the
option chain, so if an `<optgroup>` is disabled, the `<option>`
elements or other `<optgroup>` elements held within it do not have
their `disabled` property set to `true`. As a result, we needed to
use the `matches` method to check if the `:disabled` state is
present for the element. The `matches` method is part of the official
standard, but it was not implemented under that name for a while and
as a result Internet Explorer only supports it under the prefixed
`msMatchesSelector` method and older versions of Webkit have it
implemented as `webkitMatchesSelector`. But once we use this method,
it appears to consistently return the expected results.
This `matches` method and prefixed predecessors are not supported in
IE 8, but they are supported in IE 9 and any browsers newer than
that. Instead of buulding a very hacky solution using
`querySelectorAll` that was brittle, I have chosen to act like
everyone else and pretend IE 8 no longer exists.
Fixes#3347Closes#4818
