This repository has been archived by the owner on Sep 5, 2024. It is now read-only.
Chips not accessible with a screen reader #8897
Labels
a11y
This issue is related to accessibility
Comments
topherfangio
added a commit
to profoundry-us/material
that referenced
this issue
Oct 20, 2016
Previously, chips had no, or very broken, support for accessibility. Make many updates to fix broken functionality and add required features. - Remove existing `aria-hidden` attributes. - Dynamically apply required `role` and `aria-owns` attributes. - Ensure `tabindex` is set properly on all elements. Particularly, you can now tab to, and navigate through, a set of chips in readonly mode. - Provide new `input-aria-label` option to identify the inputs. - Provide new `container-hint` option used when the element is in readonly mode. - Provide new `md-chip-append-delay` option which controls the delay (in ms) before a user can add a new chip (fixes screen readers). - Fix issue with `delete-hint` never being read by screen readers because it was outside of the chip. - Fix keyboard navigation to properly wrap when moving both left or right. - Fix keyboard navigation when in readonly mode. - Fix issue where the wrong chip may be focused because the old chip was still in the DOM. - Fix issue where `onAdd` callback passed incorrect `$index` (it was 1-based instead of 0-based). Additionally update the Chips docs with new Accessibility info and a few other minor changes to the docs/demos. - Remove the "WORK IN PROGRESS" notice. - Fix mispelling of "maximum" on first chips demo. - Fix Contact Chips demo filtering. - Fix Contact Chips demo images to use new/faster service. BREAKING CHANGES **MAJOR** In order to make the chips fully accessible and work properly across a wide variety of screen readers, we have added a 300ms delay after appending a chip before we re-focus the input. This is necessary because some screen readers change operational modes when the enter key is pressed inside of an input and this causes the screen reader to move into "navigation" mode and no longer apply keystrokes to the input. Additionally, this ensures that the newly added chip is properly announced to the screen readers. You **may** alter this value with the new `md-chip-append-delay` attribute, however using a value less than `300` can cause issues on JAWS and NVDA and will make your application inaccessible to those users. Note 1: This issue only seems to affect chips appended when using the `enter` key. If you override the `md-separator-keys` and disable the `enter` key (and enable something like `,` or `;`), you may be able to reduce this delay to `0` and achieve past functionality. Note 2: This issue does not appear to affect VoiceOver or ChromeVox, so if you are only targeting those users, you may be able to reduce the delay to `0`. **MINOR** We consider the following to be minor breaking changes since we never expected these attributes/elements to be utilized by developers. Nonetheless, we want to ensure that they are documented. - The `role` of the `.md-chip-content` has been modified from `button` to `option` so that it works with the new `listbox` role of it's parent. If you rely on this role being `button`, you should update your code accordingly. - The delete hint on removable chips now resides inside of the `div.md-chip-content` rather than the parent `md-chip` element where it could not be read by screen readers. If you interact with this element (in CSS or JS) please update your selectors/code to account for the new DOM hierarchy. Fixes angular#9391. Fixes angular#9556. Fixes angular#8897. Fixes angular#8867. Fixes angular#9649.
topherfangio
added a commit
to profoundry-us/material
that referenced
this issue
Jan 4, 2017
Previously, chips had no, or very broken, support for accessibility. Make many updates to fix broken functionality and add required features. - Remove existing `aria-hidden` attributes. - Dynamically apply required `role` and `aria-owns` attributes. - Ensure `tabindex` is set properly on all elements. Particularly, you can now tab to, and navigate through, a set of chips in readonly mode. - Provide new `input-aria-label` option to identify the inputs. - Provide new `container-hint` option used when the element is in readonly mode. - Provide new `md-chip-append-delay` option which controls the delay (in ms) before a user can add a new chip (fixes screen readers). - Fix issue with `delete-hint` never being read by screen readers because it was outside of the chip. - Fix keyboard navigation to properly wrap when moving both left or right. - Fix keyboard navigation when in readonly mode. - Fix issue where the wrong chip may be focused because the old chip was still in the DOM. - Fix issue where `onAdd` callback passed incorrect `$index` (it was 1-based instead of 0-based). Additionally update the Chips docs with new Accessibility info and a few other minor changes to the docs/demos. - Remove the "WORK IN PROGRESS" notice. - Fix mispelling of "maximum" on first chips demo. - Fix Contact Chips demo filtering. - Fix Contact Chips demo images to use new/faster service. BREAKING CHANGES **MAJOR** In order to make the chips fully accessible and work properly across a wide variety of screen readers, we have added a 300ms delay after appending a chip before we re-focus the input. This is necessary because some screen readers change operational modes when the enter key is pressed inside of an input and this causes the screen reader to move into "navigation" mode and no longer apply keystrokes to the input. Additionally, this ensures that the newly added chip is properly announced to the screen readers. You **may** alter this value with the new `md-chip-append-delay` attribute, however using a value less than `300` can cause issues on JAWS and NVDA and will make your application inaccessible to those users. Note 1: This issue only seems to affect chips appended when using the `enter` key. If you override the `md-separator-keys` and disable the `enter` key (and enable something like `,` or `;`), you may be able to reduce this delay to `0` and achieve past functionality. Note 2: This issue does not appear to affect VoiceOver or ChromeVox, so if you are only targeting those users, you may be able to reduce the delay to `0`. **MINOR** We consider the following to be minor breaking changes since we never expected these attributes/elements to be utilized by developers. Nonetheless, we want to ensure that they are documented. - The `role` of the `.md-chip-content` has been modified from `button` to `option` so that it works with the new `listbox` role of it's parent. If you rely on this role being `button`, you should update your code accordingly. - The delete hint on removable chips now resides inside of the `div.md-chip-content` rather than the parent `md-chip` element where it could not be read by screen readers. If you interact with this element (in CSS or JS) please update your selectors/code to account for the new DOM hierarchy. Fixes angular#9391. Fixes angular#9556. Fixes angular#8897. Fixes angular#8867. Fixes angular#9649.
davidenochk
pushed a commit
to davidenochk/material
that referenced
this issue
Feb 3, 2017
Fixes angular#9391. Fixes angular#9556. Fixes angular#8897. Fixes angular#8867. Fixes angular#9649.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Actual Behavior:
While chips work great with the keyboard alone, they are inaccessible with screen readers for a few reasons:
aria-hidden="true", so it essentially doesn't exist for a screen reader user. How will they interact with chips without some other affordance?aria-hidden="true".What is the expected behavior?
Chips should be usable with a screen reader running. Users should be able to determine what a chip is, how many there are, and how to delete them without seeing the screen.
This component needs an accessible UX review to decide the appropriate roles and interactions for screen reader users. Off the top of my head I'm not sure what the right roles would be–ARIA menus and tabs aren't really appropriate, even if they might help with the arrow keys in a screen reader. You're focused on an input field the whole time, so it's not immediately obvious what the right pattern would be. Keep in mind the responsive nature of this framework means it should also work with a screen reader on a touch device, but I recognize even getting it to work on desktop will be a challenge.
Details (or steps to reproduce the issue): *
Visit the Chips demo on https://material.angularjs.org in Safari or Chrome with Voiceover running. On Windows, the issue is reproducible with NVDA and JAWS.
Screenshot: Arrow keys in a screen reader do not select chips. Focus is in the input field, but virtual cursor is on h2 heading after pressing the left arrow key
Angular Versions: *
All
Additional Information:
Browser Type: *Browser Version: *OS: *Stack Traces:All
Shortcut to create a new CodePen Demo.
Note:
*indicates required information. Without this information, your issue may be auto-closed.The text was updated successfully, but these errors were encountered: