e5131d0cc8
1 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Kevin Brown
|
e5131d0cc8
|
Set the main ARIA 1.1 roles and properties for comboboxes (#5582)
* 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. |