You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of our DatePicker has serious usability and keyboard accessibility issues. We've been relying on a third party library for our calendar drop down functionality and a refactor involving an in-house solution could greatly simplify component API, debugging, and accessibility bug fixes moving forward.
As for guidance -- there are browser date picker defaults that are quite accessible and building on top or these seems like the smart move. As an alternative the jQuery UI Datepicker has historically been highly regarded from a keyboard accessibility/screen reader standpoint.
Re-evaluating our Datepicker's calendar dropdown functionality has value as well. I suggest we take a cue from the Gov.uk design system and rethink this interaction altogether.
After talking about this last year (circa October?) we chose to shore up any existing issues and move forward with FlatPicker as our calendar libarary
Given this latest crop of accessibility issues for keyboard, JAWS, and VO -- I think there's value in returning to the discussion of alternatives here if the cost makes sense. For example Airbnb's React-Dates seems very thoughtfully implemented in terms of screen reader a11y and reads quite well in JAWS and VoiceOver
@carbon-design-system/developers pinging the team for thoughts and input
The text was updated successfully, but these errors were encountered:
dakahn
changed the title
Refactor DatePicker in to be more usable and keyboard accessible
Refactor DatePicker to be more usable and keyboard accessible
Nov 22, 2019
dakahn
changed the title
Refactor DatePicker to be more usable and keyboard accessible
[PROPOSAL] Refactor DatePicker to be more accessible to screen reader and keyboard users
Feb 10, 2020
The current implementation of our DatePicker has serious usability and keyboard accessibility issues. We've been relying on a third party library for our calendar drop down functionality and a refactor involving an in-house solution could greatly simplify component API, debugging, and accessibility bug fixes moving forward.As for guidance -- there are browser date picker defaults that are quite accessible and building on top or these seems like the smart move. As an alternative the jQuery UI Datepicker has historically been highly regarded from a keyboard accessibility/screen reader standpoint.Re-evaluating our Datepicker's calendar dropdown functionality has value as well. I suggest we take a cue from the Gov.uk design system and rethink this interaction altogether.
After talking about this last year (circa October?) we chose to shore up any existing issues and move forward with FlatPicker as our calendar libarary
Update 2/10/20
ref #5310
Given this latest crop of accessibility issues for keyboard, JAWS, and VO -- I think there's value in returning to the discussion of alternatives here if the cost makes sense. For example Airbnb's React-Dates seems very thoughtfully implemented in terms of screen reader a11y and reads quite well in JAWS and VoiceOver
@carbon-design-system/developers pinging the team for thoughts and input
The text was updated successfully, but these errors were encountered: