-
Bug
-
Resolution: Unresolved
-
High
-
Severity 3 - Minor
-
Accessibility
Issue Summary
When a screen reader user navigates to the "Select Component" combo box, they face several accessibility challenges. These issues prevent users from fully understanding and interacting with the dropdown field.
Steps to Reproduce
- Open the Uptime page on the StatusPage product.
- Use keyboard navigation (Tab) to focus on the "Select Component" combo box.
- Activate a screen reader and listen for announcements on the component, state (open/closed), labels, and the selected option
Screenshot
Actual Results
When the user navigates to the "Select Component" combo box, the following problems are faced by screen reader users:
- Screen readers do not correctly identify the component as a single-select dropdown.
- The state of the dropdown (open/closed) is not communicated to the user.
- The input field does not have clear labels for screen reader users, causing confusion about its purpose.
- Users are not informed of the currently selected option in the dropdown, leaving them unaware of their selection.
As a result, users of assistive technologies will not be able to understand the purpose or the functionality associated with the form field.
Expected Results
Making custom combobox accessible implement following things→
- role="combobox" and aria-autocomplete="list" to the <input> element to announce correct role for this field.
- aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on expanded/ collapsed state of combobox.
- <ul> element with role=”listbox” and unique id.
- “aria-owns” attribute to <input> element having value of id property of <ul> element.
- role=”option” and unique id to the <li> elements present under <ul> element.
- aria-activedescendant property to the <input> element having value as id property of <li> element
For more details on implementation, please see this example → https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-select-only.html
Workaround
Required, if there is no workaround please state:
Currently there is no known workaround for this behavior. A workaround will be added here when available
Environment
MacBook Pro (16-inch, 2021)
macOS: Sonoma 14.2.1.
Chrome - Version 119.0.6045.105 (Official Build) (64-bit)
Firefox- Version 92.0 (64-bit)
Safari- Version 16.6 (18615.3.12.11.2)
JAWS- Version 2023
NVDA- Version 2021.2
Voiceover - Version Latest
[STATUS-949] Select only combobox is inaccessible for screen reader users
Labels | Original: 4.1.2 ax-a11y-1123 ax-at-user ax-customer-escalated ax-eap-support ax-esc-Atlassian ax-qa level-A wcag2.2 | New: 4.1.2 ax-a11y-1123 ax-at-user ax-customer-escalated ax-eap-support ax-esc-Atlassian ax-high-priority ax-qa level-A wcag2.2 |
Description |
Original:
h3. Issue Summary
When a screen reader user navigates to the "Select Component" combo box, they face several accessibility challenges. These issues prevent users from fully understanding and interacting with the dropdown field. h3. Steps to Reproduce # Open the Uptime page on the StatusPage product. # Use keyboard navigation (Tab) to focus on the "Select Component" combo box. # Activate a screen reader and listen for announcements on the component, state (open/closed), labels, and the selected option h3.Screenshot h3. Actual Results When the user navigates to the "Select Component" combo box, the following problems are faced by screen reader users: * Screen readers do not correctly identify the component as a single-select dropdown. * The state of the dropdown (open/closed) is not communicated to the user. * The input field does not have clear labels for screen reader users, causing confusion about its purpose. * Users are not informed of the currently selected option in the dropdown, leaving them unaware of their selection. As a result, users of assistive technologies will not be able to understand the purpose or the functionality associated with the form field. h3. Expected Results Making custom combobox accessible implement following things→ * role="combobox" and aria-autocomplete="list" to the <input> element to announce correct role for this field. * aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on expanded/ collapsed state of combobox. * <ul> element with role=”listbox” and unique id. * “aria-owns” attribute to <input> element having value of id property of <ul> element. * role=”option” and unique id to the <li> elements present under <ul> element. * aria-activedescendant property to the <input> element having value as id property of <li> element For more details on implementation, please see this example → https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-select-only.html h3. Workaround Required, if there is no workaround please state: Currently there is no known workaround for this behavior. A workaround will be added here when available h3.Environment MacBook Pro (16-inch, 2021) macOS: Sonoma 14.2.1. Chrome - Version 119.0.6045.105 (Official Build) (64-bit) Firefox- Version 92.0 (64-bit) Safari- Version 16.6 (18615.3.12.11.2) JAWS- Version 2023 NVDA- Version 2021.2 Voiceover - Version Latest |
New:
h3. Issue Summary
When a screen reader user navigates to the "Select Component" combo box, they face several accessibility challenges. These issues prevent users from fully understanding and interacting with the dropdown field. h3. Steps to Reproduce # Open the Uptime page on the StatusPage product. # Use keyboard navigation (Tab) to focus on the "Select Component" combo box. # Activate a screen reader and listen for announcements on the component, state (open/closed), labels, and the selected option h3.Screenshot !Screenshot 2025-02-18 at 6.07.28 PM.png|thumbnail! h3. Actual Results When the user navigates to the "Select Component" combo box, the following problems are faced by screen reader users: * Screen readers do not correctly identify the component as a single-select dropdown. * The state of the dropdown (open/closed) is not communicated to the user. * The input field does not have clear labels for screen reader users, causing confusion about its purpose. * Users are not informed of the currently selected option in the dropdown, leaving them unaware of their selection. As a result, users of assistive technologies will not be able to understand the purpose or the functionality associated with the form field. h3. Expected Results Making custom combobox accessible implement following things→ * role="combobox" and aria-autocomplete="list" to the <input> element to announce correct role for this field. * aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on expanded/ collapsed state of combobox. * <ul> element with role=”listbox” and unique id. * “aria-owns” attribute to <input> element having value of id property of <ul> element. * role=”option” and unique id to the <li> elements present under <ul> element. * aria-activedescendant property to the <input> element having value as id property of <li> element For more details on implementation, please see this example → https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-select-only.html h3. Workaround Required, if there is no workaround please state: Currently there is no known workaround for this behavior. A workaround will be added here when available h3.Environment MacBook Pro (16-inch, 2021) macOS: Sonoma 14.2.1. Chrome - Version 119.0.6045.105 (Official Build) (64-bit) Firefox- Version 92.0 (64-bit) Safari- Version 16.6 (18615.3.12.11.2) JAWS- Version 2023 NVDA- Version 2021.2 Voiceover - Version Latest |
Labels | Original: 4.1.2 ax-at-user ax-customer-escalated ax-eap-support ax-esc-Atlassian ax-qa level-A wcag2.2 | New: 4.1.2 ax-a11y-1123 ax-at-user ax-customer-escalated ax-eap-support ax-esc-Atlassian ax-qa level-A wcag2.2 |
Remote Link | New: This issue links to "Page (Confluence)" [ 999605 ] |
Assignee | Original: Avinash Yadav [ d6cd99910201 ] | New: Manas Ranjan Patel [ 9932bb248208 ] |
Description |
Original:
h3. Issue Summary
When a screen reader user navigates to the "Select Component" combo box, they face several accessibility challenges. These issues prevent users from fully understanding and interacting with the dropdown field. h3. Steps to Reproduce # Open the Uptime page on the StatusPage product. # Use keyboard navigation (Tab) to focus on the "Select Component" combo box. # Activate a screen reader and listen for announcements on the component, state (open/closed), labels, and the selected option h3.Screenshot h3. Actual Results When the user navigates to the "Select Component" combo box, the following problems are faced by screen reader users: * Screen readers do not correctly identify the component as a single-select dropdown. * The state of the dropdown (open/closed) is not communicated to the user. * The input field does not have clear labels for screen reader users, causing confusion about its purpose. * Users are not informed of the currently selected option in the dropdown, leaving them unaware of their selection. As a result, users of assistive technologies will not be able to understand the purpose or the functionality associated with the form field. h3. Expected Results Making custom combobox accessible implement following things→ * role="combobox" and aria-autocomplete="list" to the <input> element to announce correct role for this field. * aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on expanded/ collapsed state of combobox. * <ul> element with role=”listbox” and unique id. * “aria-owns” attribute to <input> element having value of id property of <ul> element. * role=”option” and unique id to the <li> elements present under <ul> element. * aria-activedescendant property to the <input> element having value as id property of <li> element For more details on implementation, please see this example → https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-select-only.html h3. Workaround Required, if there is no workaround please state: Currently there is no known workaround for this behavior. A workaround will be added here when available |
New:
h3. Issue Summary
When a screen reader user navigates to the "Select Component" combo box, they face several accessibility challenges. These issues prevent users from fully understanding and interacting with the dropdown field. h3. Steps to Reproduce # Open the Uptime page on the StatusPage product. # Use keyboard navigation (Tab) to focus on the "Select Component" combo box. # Activate a screen reader and listen for announcements on the component, state (open/closed), labels, and the selected option h3.Screenshot h3. Actual Results When the user navigates to the "Select Component" combo box, the following problems are faced by screen reader users: * Screen readers do not correctly identify the component as a single-select dropdown. * The state of the dropdown (open/closed) is not communicated to the user. * The input field does not have clear labels for screen reader users, causing confusion about its purpose. * Users are not informed of the currently selected option in the dropdown, leaving them unaware of their selection. As a result, users of assistive technologies will not be able to understand the purpose or the functionality associated with the form field. h3. Expected Results Making custom combobox accessible implement following things→ * role="combobox" and aria-autocomplete="list" to the <input> element to announce correct role for this field. * aria-expanded property to the <input> element and toggle its value programmatically to true/ false depending on expanded/ collapsed state of combobox. * <ul> element with role=”listbox” and unique id. * “aria-owns” attribute to <input> element having value of id property of <ul> element. * role=”option” and unique id to the <li> elements present under <ul> element. * aria-activedescendant property to the <input> element having value as id property of <li> element For more details on implementation, please see this example → https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-select-only.html h3. Workaround Required, if there is no workaround please state: Currently there is no known workaround for this behavior. A workaround will be added here when available h3.Environment MacBook Pro (16-inch, 2021) macOS: Sonoma 14.2.1. Chrome - Version 119.0.6045.105 (Official Build) (64-bit) Firefox- Version 92.0 (64-bit) Safari- Version 16.6 (18615.3.12.11.2) JAWS- Version 2023 NVDA- Version 2021.2 Voiceover - Version Latest |
Remote Link | New: This issue links to "Page (Confluence)" [ 991444 ] |
Development Effort | New: M [ 13032 ] | |
Status | Original: Needs Triage [ 10030 ] | New: Gathering Impact [ 12072 ] |
Assignee | New: Avinash Yadav [ d6cd99910201 ] |
Remote Link | New: This issue links to "Page (Confluence)" [ 989503 ] |