-
Bug
-
Resolution: Fixed
-
Low
-
8.9.0, 8.13.0
-
Severity 3 - Minor
-
Issue Summary
The "State" combobox functionality is inaccessible for screen reader users.
Additionally, this combobox is coded using native and custom approaches but none of these are fully accessible for screen reader users.
Note: A similar issue is found on the "Repositories" page.
Steps to Reproduce
- Navigate to the mentioned page.
- Try to access custom mentioned comboboxes. Observe it is not accessible.
- Try to navigate to native comboboxes in read mode and observe that it is missing an accessible name.
Screenshot 1: Pull request page
Screenshot 2: Repositories page
Actual Results
The role is not provided for the “State” custom combobox.
Following problems found with custom combobox →
- The custom combobox is missing the role of combobox.
- The option coded at the end of the page source code.
- role=”option” is missing for combobox options.
Due to this, screen reader users may not be able to use the functionality effectively.
The problem found with native comboboxes is that the select-only comboboxes are coded in the tabindex=”-1” property due to which it is available in read mode.
As a result, comboboxes are inaccessible to screen reader users.
Expected Results
The combobox components should be correctly programmatically determined. Since there are already hidden native dropdowns in the DOM, we would recommend to remove the “tabindex=”-1” property from the <select> elements. Also, hide the custom combobox i.e <input> element and its options from the users. The native dropdowns have out-of-the-box accessibility.
Alternatively,
Making custom combobox accessible →
- role="combobox" and aria-autocomplete="list" to the <input> element to announce the correct role for this field.
- aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on the expanded/ collapsed state of combobox.
- <div> element with role=”listbox” and a unique id.
- “aria-owns” attribute to <input> element having value of id property of <div> element.
- role=”option” and unique id to the <div> elements present for options present for combobx.
- aria-activedescendant property to the <input> element having value as id property of <li> element.
- Code options just after the triggering element in the source code.
Workaround
Currently, there is no known workaround for this behaviour.
Environment
MacBook Pro (16-inch, 2019)
macOS 13.4.1 (c) (22F770820d)
Chrome - Version 115.0.5790.170 (Official Build) (x86_64)
Firefox- Version 114.0 (64-bit)
Safari- Version 16.5.2 (18615.2.9.11.10)
JAWS- Version 2023.2306.28
NVDA- Version 2022.2.2
Voiceover - Version Latest
Pull Request: Combobox inaccessible for screen reader users
-
Bug
-
Resolution: Fixed
-
Low
-
8.9.0, 8.13.0
-
Severity 3 - Minor
-
Issue Summary
The "State" combobox functionality is inaccessible for screen reader users.
Additionally, this combobox is coded using native and custom approaches but none of these are fully accessible for screen reader users.
Note: A similar issue is found on the "Repositories" page.
Steps to Reproduce
- Navigate to the mentioned page.
- Try to access custom mentioned comboboxes. Observe it is not accessible.
- Try to navigate to native comboboxes in read mode and observe that it is missing an accessible name.
Screenshot 1: Pull request page
Screenshot 2: Repositories page
Actual Results
The role is not provided for the “State” custom combobox.
Following problems found with custom combobox →
- The custom combobox is missing the role of combobox.
- The option coded at the end of the page source code.
- role=”option” is missing for combobox options.
Due to this, screen reader users may not be able to use the functionality effectively.
The problem found with native comboboxes is that the select-only comboboxes are coded in the tabindex=”-1” property due to which it is available in read mode.
As a result, comboboxes are inaccessible to screen reader users.
Expected Results
The combobox components should be correctly programmatically determined. Since there are already hidden native dropdowns in the DOM, we would recommend to remove the “tabindex=”-1” property from the <select> elements. Also, hide the custom combobox i.e <input> element and its options from the users. The native dropdowns have out-of-the-box accessibility.
Alternatively,
Making custom combobox accessible →
- role="combobox" and aria-autocomplete="list" to the <input> element to announce the correct role for this field.
- aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on the expanded/ collapsed state of combobox.
- <div> element with role=”listbox” and a unique id.
- “aria-owns” attribute to <input> element having value of id property of <div> element.
- role=”option” and unique id to the <div> elements present for options present for combobx.
- aria-activedescendant property to the <input> element having value as id property of <li> element.
- Code options just after the triggering element in the source code.
Workaround
Currently, there is no known workaround for this behaviour.
Environment
MacBook Pro (16-inch, 2019)
macOS 13.4.1 (c) (22F770820d)
Chrome - Version 115.0.5790.170 (Official Build) (x86_64)
Firefox- Version 114.0 (64-bit)
Safari- Version 16.5.2 (18615.2.9.11.10)
JAWS- Version 2023.2306.28
NVDA- Version 2022.2.2
Voiceover - Version Latest