Feature/accessibility #1503

dmtrKovalenko · 2020-02-10T10:11:09Z

This PR closes #1462

Description

PR is giantly improving accessibility of pickers.

vercel · 2020-02-10T10:11:15Z

This pull request is being automatically deployed with ZEIT Now (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/mui-org/material-ui-pickers/lhzbsti2x
✅ Preview: https://material-ui-pickers-git-feature-accessibility.mui-org.now.sh

dmtrKovalenko · 2020-02-10T10:13:05Z

@ahayes91 if you could take a look on the deployment preview of this PR to check accessibility changes - you will really help!

dmtrKovalenko · 2020-02-10T10:11:38Z

lib/src/DateTimePicker/DateTimePickerTabs.tsx

@@ -71,8 +71,8 @@ export const DateTimePickerTabs: React.SFC<DateTimePickerTabsProps> = ({
        className={classes.tabs}
        indicatorColor={indicatorColor}
      >
-        <Tab value="date" icon={<>{dateRangeIcon}</>} />
-        <Tab value="time" icon={<>{timeIcon}</>} />
+        <Tab value="date" aria-label="pick date" icon={<>{dateRangeIcon}</>} />


Todo make replaceable

cypress · 2020-02-10T10:14:20Z

Test summary

57 • 0 • 1 • 0

Run details


Project	material-ui-pickers
Status	Passed
Commit	`7716d26`
Started	Feb 13, 2020 2:50 PM
Ended	Feb 13, 2020 2:51 PM
Duration	01:00 💡
OS	Linux Debian - 9.8
Browser	Electron 61

View run in Cypress Dashboard ➡️

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

ahayes91 · 2020-02-10T11:02:59Z

@ahayes91 if you could take a look on the deployment preview of this PR to check accessibility changes - you will really help!

Sure, I'd be very happy to test this out - I'll go with a few SR/browser combinations. ~~I'll start a comment here but it'll probably take me all day to fill it out so I'll remove this WORK IN PROGRESS comment whenever I'm done 😁~~

Overall issues:

Mobile version is not compatible with VoiceOver & Safari on iOS or with Talkback on Android at all
The placeholder of 01/01/2019 is confusing - something like mm/dd/yyyy should be used instead like in https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html. (My preference is American format like the examples, but perhaps this could/should be configurable).
Enter key cannot be used to interact with the buttons on the datepicker dialog, instead the Enter key will just close the dialog.
When the datepicker is opened focus is not always set correctly - it should be set on the currently chosen date in the dialog.
Typing/reading out the date is too literal and includes the underscores - it should read out the date in a date format (like in https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html)
The year dropdown functionality is unreliable across the screenreaders - nothing is announced when it is opened on NVDA, there is no way to choose a year with JAWS using only the keyboard...
Choosing the date does not close the dialog or update focus correctly with NVDA and FireFox.

VoiceOver + Chrome, MacOS

Tab navigating to the input shows focus correctly on the date input field and reads: "02/10/2020, contents selected, 01/01/2019, edit text. You are currently on a text field. To enter text in this field, type."
Typing in the field will read out underscores even though the user hasn't typed any underscores.
If the user types in an invalid date (e.g. 02/31/2020) the "Invalid date" message appears but it is not read out to the user. It's also not clear what date format should be followed (it's mm/dd/yyyy here but there are no audio or visual indicators about this).
There's probably an issue here with the placeholder text - when I cleared the input with my keyboard backspace keys, "01/01/2019" appeared and that explains what's being read out on first tab.
Tab navigation to the calendar button shows focus correctly on the calendar button and reads:
"Choose date, the selected date is 28th of February, 2020, button. You are currently on a button. To click this button, press Control-Option-Space."
Control Option Space opens the dialog, but focus stays on the calendar button, and reads "February and 2 more items, dialog, February and 2 more items, group, February February, 2020 2020, You are currently on a group, inside web content. To interact with items in this group press Control Option Shift Down Arrow, To exit this web area, press Control Option Shift Up Arrow". Pressing Control Option Shift Down Arrow does nothing. Pressing Control Option Shift Up Arrow reads "Out of Datepicker - @material-ui/pickers component, web content" but doesn't close the dialog, and moves the focus to the whole screen.
The Space key will click the button and open the date dialog, but the focus ring disappears, and reads "02/10/2020 selected, February February, 2020, 2020, You are currently on a text field, inside web content. To enter text in this field, type. To exit this web area, press Control Option Shift Up arrow". Hitting the Space key again does nothing. On https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html, the focus is moved automatically to the current date button, and hitting the Space key again chooses that same date and closes the dialog.
Tab navigating when the calendar is open is causing Chrome to crash - I restarted my laptop but this is still happening when VoiceOver is on 💥 ❌
The same thing just happened for me on https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker too 💥 This could be a Chrome issue with the latest update to Version 80, so I'll have a look online.

VoiceOver + Safari, Mac OS

Tab navigation to the basic example brings focus correctly to the input and reads: "02/10/2020 contents selected, 01/01/2019, Edit text. 01.01/2019, You are currently on a text field. To enter text in this field, type." The placeholder is being read out incorrectly here again.
Typing "2" into the field reads out: "2_/__/____, edit text, invalid data. 01.01/2019, You are currently on a text field. To enter text in this field, type.". Again, underscores being read out incorrectly here and no indication of what a date should look like.
Tab navigation will bring focus to the calendar button and read "Choose date, button. You are currently on a button. To click this button, press Control Option Space.". Pressing Control Option Space will open the dialog, bring the focus to "February", and read "February and 11 more items, web dialog, February and 11 more items, group. You are currently on a heading level 6, inside web content. To exit this web area, press Control-Option-Shift-Up arrow.". Pressing Control Option Space again will read "heading level 6, February". Pressing the space key does nothing, and pressing Enter will close the dialog.
Tab navigation when the dialog is open will bring focus to the year dropdown button and read "Calendar view is open, switch to year view, button. You are currently on a button, inside web content. To click this button, press Control-Option-Space. To exit this web area, press Control-Option-Shift-Up arrow." Pressing Control Option Space will read "Press year view is open, switch to calendar view button". Tab navigation will bring you to "2020, button". Tab navigation again will only let you move between the 2020 button and the calendar dropdown button. Arrow navigation allows you to move between year options, which are read out as "2021, button". Pressing Space or Control Option Space will choose that year, reopen the calendar view, but the focus is still visually in the same place as the year button. The Februrary 2021 group is read out again. Here, I think the focus should be brought back to the chosen date.
Tab navigation allows you to get to the previous and next month buttons correctly, but hitting Space or Control Option Space on them will read "January, January. You are currently on a button inside web content. To click this button, press Control Option Space. To exit this web area, press Control Option Shift Up arrow."
Pressing the Enter key on any of the year dropdown or next/previous month buttons will close the dialog instead of interacting with that button.
Find next control mode (Control Option Cmd J) will find the input field correctly.
Pressing ESC will close the dialog correctly but it will also minimize the Safari window itself.

VoiceOver + Safari, iOS

Swipe navigation will bring you to "Basic example" label, and then swiping again will bring you to the input which reads: "02 slash 10 slash 2020, text field, read-only. Double tab to edit. Use the rotor to access misspelled words." Double-tapping on the screen will open the dialog with the focus still in the shape of the input, as per the screenshot below, and reads "02 slash 10 slash 2020, text field, read-only.":

Left and right or up and down swiping won't allow you to do anything.
Unless you can actually see the screen, you can't interact with the dialog at all. ❌

ChromeVox + Chrome, Dell Chromebook

Tab navigating to the input moves the focus on the input correctly and announces: "01 slash 01 slash 2019, 02 slash 02 slash 2020, selected, Edit text numeric only." (Looks like the same issue with the placeholder being read out here).
Typing "03" will read out: "01 slash 01 slash 2019, 0_ slash 2 underscores slash 4 underscores Edit text numeric only". (Same issue with both the placeholder being read out, and the underscores, and no indication of what input is expected). The invalid date format label also appears but nothing is actually read out to the user either.
Tab navigating to the calendar button will move focus to it correctly and read out: "Choose date, button, press Search + Space to activate". Pressing "Search + Space" will open the dialog, but the focus is still on the calendar button. "February, Heading 6, 2020 Heading 6" is read out." Pressing Search + Space again doesn't do anything.
Hitting tab will move the focus to the dropdown picker beside "February 2020" and read "Dialog, calendar view is open, switch to year view Button Press Search plus Space to activate". Pressing Search + Space will switch the visual direction of the arrow on the button and read "year view is open, switch to calendar view, Button Press Search plus Space to activate". Using the right arrow key will move the focus to the next year and read "2021, Heading 6". I would think that this should be read out as a button or something interact-able. Pressing Space will close the year view and open the calendar view, with focus on the whole dialog and read: "February 2021 calendar view is open, switch to year view previous month next month S M T W T F S jan 31, 2021. Feb 1, 20201. Feb 2, 2021....." and continue reading out all the elements in the calendar.
I think the focus should probably move back to the current date in this case for a better experience.
https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html doesn't have a year dropdown picker in the same way so it's not really comparable in this case... https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker is another pretty a11y example that also doesn't have a year dropdown...
Tabbing from the year dropdown will bring the focus to the previous month button and read "previous month, Press Search + Space to activate". Pressing Search + Space will leave the focus on the previous month button and read "January, heading 6". Pressing the Enter key on this button will close the dialog, and move the focus back to the calendar button. That doesn't match the behaviour of https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html , where both "Enter" and "Space" keys can be used to interact with the previous/next month buttons.
Tabbing from the next month button will bring the focus to the current date and read "Feb 10, 2020 Button, row 3 column 2 Table, 5 by 7, Press Search plus Space to activate. Press Search plus Ctrl plus Alt with arrows to navigate by cell". Pressing "Search plus Space" doesn't do anything at all. Pressing "Search plus Ctrl plus Alt with right arrow" will move the focus to the next date and read "Feb 11, 2020, Button, row 3 column 3, Press Search plus Space to activate". Pressing Search plus Space will move the green date focus to the "11" button, but nothing is read out to the user and the dialog is still open. Clicking the Space button only will close the dialog, with the focus on the calendar button and "Chose date, selected date is February 11, 2020, Button Main Press Search plus Space to activate". If you open the dialog again, the green focus is on 11 but there is still a circle on 10:
Hitting the ESC key when the dialog is open will correctly close the dialog.
Using form navigation (Search + f) will bring you correctly to the date input.

JAWS 2019 + Chrome, Windows 10

Tab navigating to the input shows the focus correctly and reads: "01/01/2019 edit, 02/10/2020, type in text". Typing in the input will only read out each character typed. Typing "31/02/2020" and then tab navigating away and back to the input will read: "01/01/2019 edit invalid entry, 31/02/2020, type in text".
Tab navigating to the calendar button shows focus correctly and reads "Choose Date, selected date is Feb 2, 2020, button. To activate press space bar". Pressing the Space bar will read out "Space", open the dialog, the focus will disappear, and reads "dialog, February 2020 calendar view is open, switch to year view previous month next month S M T W T F S heading level 6". Pressing Space again does nothing other than read "Space". Pressing Enter does nothing other than read "Enter". Pressing ESC reads "ESC", closes the dialog, and reads "Main region, Choose date, selected date is Feb 10 2020, button, to activate press space bar." with the focus on the calendar button.
Tab navigating while the dialog is open moves the focus to the year dropdown and reads "Calendar view is open, switch to year view button, to activate press space bar". Pressing Space reads "Space" but nothing else, even though visually the picker has updated to show year options. Tabbing will bring you to "2020 button". "Alt Shift arrow keys" can be used to move between the year options but the focus doesn't seem to match what's happening visually - it's read out as "2021 button, year view is open, switch to calendar view button, to activate press space bar". There doesn't seem to be any way to choose another year option. ❌
-Tab navigation brings you to the previous month button with focus "previous month button, to activate press space bar", and pressing Space on previous month button will just announce "space" and nothing else even though the calendar has updated visually.
Alt + Arrow keys can be used to move between date options - Enter or Space will choose that date and close the dialog.
Form mode (F key) will bring you correctly to the date input.

NVDA + FireFox, Windows 10

Tab navigation to the input brings the focus correctly to the input (and focus mode is activated with the focus mode sound) and reads "01/01/2019 edit has autocomplete. Selected 02/10/2020." Typing "2" into this field reads "2, invalid entry".
Tab navigating to the calendar button brings focus to the button and reads "Choose date, selected date is February 2nd, 2020, button". Pressing space opens the dialog, but the focus is not apparent, and announces "Dialog, February heading level 6 2020 heading level 6. Calendar view is open. switch to year view button previous month button S M T W T F S..." and reads out all the rest of the buttons on the calendar. Focus is incorrect here again and would be better on the current date. Hitting the space button will stop the announcements, but nothing happens. Tab will bring you to the year dropdown button and announce "calendar view is open, switch to year view button". Hitting Space on this button will change the calendar visually but nothing is announced to the user. Hitting Space again will change back to the date view.
When the date dialog (calendar view) is open, tabbing can be used to get to the previous and next month buttons. Hitting "Enter" on the previous month button will change the visual state of the component but it won't announce anything to the user. Hitting "Space" on the previous month button is the same.
Tabbing past the next month button brings you to the currently chosen date and reads "table with 5 rows and 7 columns, row 3 column 2 clickable February 10 2020 button". Pressing "Space" or "Enter" on this button doesn't do anything. Alt and right arrow key will not change the focus, but "column 3 clickable February 11th 2020 button" will be announced. Pressing "Space" or "Enter" will change the green selection, but a grey circle still remains on the 10 option and the dialog is still open. Pressing ESC will close the dialog and show that the selected date is whatever was green (February 11 2020).
ESC will correctly close the dialog and move focus to the calendar button.
Form mode (F) will bring focus to the input and announce "Clickable 01/01/2019 edit has autocomplete. 02/11/2020". It will not bring you to focus mode until you click "Enter" or "Space".

Talkback + Chrome, Moto G6 Android V9

Swiping brings you to the input, but double tapping does nothing. You can't interact with the input at all ❌

oliviertassinari · 2020-02-10T16:09:24Z

@ahayes91 Oh wow, thank you so much for diving deep in the accessibility of the component! This is one of the best reviews I have seen from the community to date! I remember similar excellent feedback grom @ryancogswell :)

oliviertassinari · 2020-02-10T16:15:01Z

lib/src/views/Calendar/Year.tsx

        color={selected ? 'primary' : undefined}
        children={children}
-        ref={forwardedRef}
+        onKeyPress={onSpaceOrEnter(() => onSelect(value))}


What motivates keypress over keydown?

oliviertassinari · 2020-02-10T16:16:23Z

lib/src/_helpers/utils.ts

+
+    // prevent any side effects
+    e.preventDefault();
+    e.stopPropagation();


I think that we should be cautious about the usage of stopPropagation. I think that it would be great to add a comment on the "why?" we use it here for our future self. https://css-tricks.com/dangers-stopping-event-propagation/

dmtrKovalenko · 2020-02-10T19:36:35Z

@ahayes91 Thank you so much for your testing! This really helps, I am in progress fixing issues. Wondering do you have twitter? I'd like to tweet about your help with pickers accessiblity 💪

But some things I noticed:

I have no idea why voiceover is duplicating year and month on chrome. The same I am seeing here https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html so I think it is chrome bug
About text input that reads mask chars 1_/__/____ I have no idea how to fix it. This looks like a real problem that requires us to remove mask at all. I think we need to make an accessibility guideline that will cover all the issues.

Can we detect screen readers and disable masked input dynamically?

Pretty same with placeholder - developer needs to pass the proper placeholder manually, because right now we are using localized formats and it looks like Pp so just fallback to the example of formatted date
Enter works like in exampe and submitting focused date, then closing dialog

oliviertassinari · 2020-02-10T20:29:12Z

@dmtrKovalenko I have used the Pagination as a workbench to experiment around the implementation of the latest "state" guidelines. I think that it's something we can leverage for the days in the calendar. Actually, we could almost use the same logic :D.

For instance, it would fix the following issue: consider the selected day, there is no visual clue that it has the focus. We can't distinguish the "selected" to the "selected + focus" state as we can in the WAI-ARIA example.
Another detail would be about the "selected + hover" state, the current implementation makes the background lighter while the material design spec seems to suggest to make it darker.

ahayes91 · 2020-02-11T10:37:02Z

@ahayes91 Thank you so much for your testing! This really helps, I am in progress fixing issues. Wondering do you have twitter? I'd like to tweet about your help with pickers accessiblity 💪

Yes indeed - @theaislinnhayes 👍

But some things I noticed:

I have no idea why voiceover is duplicating year and month on chrome. The same I am seeing here https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html so I think it is chrome bug

If you're seeing the same on that example or on another accessible example https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker then I'd say don't worry about it - Chrome's got its own problems anyway given that version 80 is definitely broken with VoiceOver 🙄

About text input that reads mask chars 1_/__/____ I have no idea how to fix it. This looks like a real problem that requires us to remove mask at all. I think we need to make an accessibility guideline that will cover all the issues.

Can we detect screen readers and disable masked input dynamically?

I'd be inclined to ditch the mask altogether to be honest. Neither of those few accessible datepicker examples that we have (https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html or https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker) use one - putting the desired format as a placeholder or in the label would be enough for context for all users, and while you'd save a couple of key presses with a mask, it really does hinder the a11y experience. To me it feels like a case of sacrificing a11y user experience for the sake of convenience for non-SR-users.
It also might not be a good idea (or even possible) to detect screenreaders and disable certain features - even though the most recent WebAim survey indicated quite a few users wouldn't mind if websites could detect use of a screenreader (https://webaim.org/projects/screenreadersurvey8/#detection), there are lots of arguments against doing so for privacy and discriminatory reasons:
https://marcozehe.wordpress.com/2014/02/27/why-screen-reader-detection-on-the-web-is-a-bad-thing/
https://www.boia.org/blog/should-you-have-a-separate-accessible-website

Pretty same with placeholder - developer needs to pass the proper placeholder manually, because right now we are using localized formats and it looks like Pp so just fallback to the example of formatted date

Can we update the demo examples to show the proper placeholder, so that developers have a better idea of what should be passed?

Enter works like in exampe and submitting focused date, then closing dialog

👍 - just retested this quickly with VoiceOver on Safari, and hitting Enter on a chosen date in the calendar view is good. The enter button doesn't work on the other buttons though (like previous/next month/ year dropdown) and it also seems like there isn't a way to choose a year from the dropdown either with Space or Enter.... I can retest this again in a few days anyway 💪

attilavago · 2020-02-11T11:08:21Z

I agree with @ahayes91, the inputs masks are not a great idea from an accessibility perspective, so they are required to be removed.

On the note of browsers detecting screen readers being used, there are much larger issues around it, like privacy and discrimination. The entire standard is built around creating user interfaces and user experiences that work for all. This is why for example keyboard accessibility results in allowing all other input methods used by the disabled communities to work very well, as they emulate the keyboard and thus are backwards compatible with all other user experiences.

dmtrKovalenko · 2020-02-11T11:12:15Z

Masks will not be removed from the datepicker. But there is an option to disable masked input

oliviertassinari · 2020-02-11T12:05:49Z

If we remove the mask support, would we save this dependency 800 B? https://bundlephobia.com/result?p=rifm@0.11.0

dmtrKovalenko · 2020-02-11T12:39:09Z

@oliviertassinari yes, but I have a strong opinion that mask is required

oliviertassinari · 2020-02-11T12:46:48Z

OK, fair enough. Maybe somebody will open an issue about it, and as the component gain adoption and the issue upvotes, we will re-evaluate in the future?
In any case, I recall that we had to set the mask disabled by default to handle localization? So it's not that much a concern?

dmtrKovalenko · 2020-02-11T12:48:31Z

Mask will be disabled for any other from en-US locale (example is here https://dev.material-ui-pickers.dev/localization/date-fns). For the other locales it needs to be enabled manually

codecov · 2020-02-13T14:47:21Z

Codecov Report

Merging #1503 into next will decrease coverage by 1.43%.
The diff coverage is 78.51%.

@@            Coverage Diff             @@
##             next    #1503      +/-   ##
==========================================
- Coverage   91.61%   90.17%   -1.44%     
==========================================
  Files          60       60              
  Lines        1502     1649     +147     
  Branches      243      282      +39     
==========================================
+ Hits         1376     1487     +111     
- Misses         93      126      +33     
- Partials       33       36       +3

Impacted Files	Coverage Δ
lib/src/Picker/Picker.tsx	`97.29% <ø> (ø)`	⬆️
lib/src/DateTimePicker/DateTimePickerToolbar.tsx	`93.33% <ø> (ø)`	⬆️
lib/src/DateTimePicker/DateTimePickerTabs.tsx	`84.84% <ø> (ø)`	⬆️
lib/src/wrappers/MobileWrapper.tsx	`100% <ø> (ø)`	⬆️
lib/src/wrappers/Wrapper.tsx	`41.66% <ø> (ø)`	⬆️
lib/src/DatePicker/DatePicker.tsx	`100% <ø> (ø)`	⬆️
lib/src/constants/prop-types.ts	`100% <ø> (ø)`	⬆️
lib/src/_shared/ModalDialog.tsx	`100% <ø> (ø)`	⬆️
lib/src/_shared/hooks/useViews.tsx	`95.65% <100%> (ø)`	⬆️
lib/src/wrappers/DesktopWrapper.tsx	`100% <100%> (ø)`	⬆️
... and 28 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7409f3...7716d26. Read the comment docs.

dmtrKovalenko · 2020-02-13T20:03:44Z

We keep loosing code coverage percentage, my experiments with collecting coverage from cypress tests are not working. Moved experiments to #1507

oliviertassinari · 2020-02-14T12:09:31Z

@dmtrKovalenko Great iteration on the accessibility of the component! Well done 😍.

I have a couple of feedback based on https://next.material-ui-pickers.dev/demo/datepicker:

What about we replace the pulsating ripple for focused days in the calendar with the focus-visible class name? It would solve this case when the popup is open with the keyboard:
When the popup is open with the keyboard, about 40% of the time, the active day isn't initially focused. I suspect a race condition, somewhere:
When a date is clicked on, the contrast goes wild
Should the popup behave like a modal? Blocking all interactions on the rest of the page? It's it a common approach? I personally feel frustrated by this behavior. There is a related issue about it in [Select][material-ui] Don't lock the body scroll and make it non-modal select material-ui#17353.
We might have a responsiveness issue. I have recorded the following for the open interaction. In this run, it takes 237ms between the mouse up and the beginning of the appearance of the calendar (transitioning).

This is, for instance, to be compared with jQuery UI (134ms):

http://react-day-picker.js.org/ seems to perform great with about 90ms of delay.

While jQuery UI feels a bit slow, I think that it would be great to look into the performance of our date picker. Google recommends 100ms as the upper boundary for a great experience :D.

ahayes91 · 2020-09-30T15:29:25Z

Have the accessibility improvements for datepicker been released yet? I couldn't figure out if this is linked to any of the latest releases 🤓

mhchen · 2020-12-02T21:01:17Z

@ahayes91 not sure if you're still waiting on an answer, but my understanding is that this went out in the 4.x alpha releases. I recently had to upgrade to 4 Alpha 10 to address these a11y issues (and thank you for being so involved in the process!). I picked 10 because it is the last one before requiring an upgrade to Material-UI core 5 Alpha. I wish these changes could've been published in a stable version, but I'm glad to be able to use them now anyway.

dmtrKovalenko added 12 commits February 3, 2020 22:10

Implement dom-based keyboard navigation for year selection

a7ee4ff

Make calendar keyboard navigation also focus-based

6c1c7df

Fix animation freesing because of .focus() in Calendar

501a8ad

Add proper aria-label's for calendar

1f05deb

Properly handle focus when switching months

60813cc

Announce month and year switching

dfbce44

Make props for customizing aria-label texts

8be5e08

Fix type for useKeyDown handler

98916ea

Add aria-label for mobile keyboard input button

c4ce41f

Fix Prop inference after changing interfaces

6166587

Implement force quitting picker onKeyDown

a387460

Aria-labels and live regions for date & time picker

80cad80

dmtrKovalenko commented Feb 10, 2020

View reviewed changes

dmtrKovalenko requested a review from oliviertassinari February 10, 2020 10:14

oliviertassinari reviewed Feb 10, 2020

View reviewed changes

Fix day and clock numbers not autofocusing on appear

d70de96

vercel bot deployed to Preview February 10, 2020 19:28 View deployment

dmtrKovalenko added 4 commits February 11, 2020 16:48

Fix missing container if reduceAnimations

cbf87eb

Better default focus management

5badc9d

Add more keyboard shorcats

12965cd

Add accessibility guide

e7398fd

vercel bot deployed to Preview February 11, 2020 15:32 View deployment

dmtrKovalenko added 2 commits February 11, 2020 23:18

Fix styles of markdown table

685224b

Fix grammar in accessibility guideline

4d700e5

vercel bot deployed to Preview February 11, 2020 21:21 View deployment

dmtrKovalenko added 4 commits February 13, 2020 10:22

Fix crashing on openning invalid date

9d82f42

Make focus visible when root element of wrapper is focused

dfc2c24

Fix not closing mobile dialog with esc

0c94104

Better match material design accessibility spec

0492aef

vercel bot deployed to Preview February 13, 2020 12:42 View deployment

dmtrKovalenko added 2 commits February 13, 2020 15:39

Fix ts error and linters

7f03584

Add keyboard navigation cypress tests

92e399e

vercel bot deployed to Preview February 13, 2020 14:37 View deployment

Skip flaky test

7716d26

vercel bot deployed to Preview February 13, 2020 14:47 View deployment

dmtrKovalenko marked this pull request as ready for review February 13, 2020 14:52

dmtrKovalenko merged commit fd86dc2 into next Feb 13, 2020

oliviertassinari deleted the feature/accessibility branch February 14, 2020 11:20

dmtrKovalenko mentioned this pull request Feb 17, 2020

(chore) Better focus displaying #1517

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/accessibility #1503

Feature/accessibility #1503

dmtrKovalenko commented Feb 10, 2020 •

edited

Loading

vercel bot commented Feb 10, 2020 •

edited

Loading

dmtrKovalenko commented Feb 10, 2020

dmtrKovalenko Feb 10, 2020

cypress bot commented Feb 10, 2020 •

edited

Loading

ahayes91 commented Feb 10, 2020 •

edited

Loading

oliviertassinari commented Feb 10, 2020 •

edited

Loading

oliviertassinari Feb 10, 2020

oliviertassinari Feb 10, 2020

dmtrKovalenko commented Feb 10, 2020

oliviertassinari commented Feb 10, 2020

ahayes91 commented Feb 11, 2020 •

edited

Loading

attilavago commented Feb 11, 2020

dmtrKovalenko commented Feb 11, 2020

oliviertassinari commented Feb 11, 2020

dmtrKovalenko commented Feb 11, 2020

oliviertassinari commented Feb 11, 2020

dmtrKovalenko commented Feb 11, 2020

codecov bot commented Feb 13, 2020 •

edited

Loading

dmtrKovalenko commented Feb 13, 2020

oliviertassinari commented Feb 14, 2020 •

edited

Loading

ahayes91 commented Sep 30, 2020

mhchen commented Dec 2, 2020

Feature/accessibility #1503

Feature/accessibility #1503

Conversation

dmtrKovalenko commented Feb 10, 2020 • edited Loading

Description

vercel bot commented Feb 10, 2020 • edited Loading

dmtrKovalenko commented Feb 10, 2020

dmtrKovalenko Feb 10, 2020

Choose a reason for hiding this comment

cypress bot commented Feb 10, 2020 • edited Loading

Test summary

Run details

ahayes91 commented Feb 10, 2020 • edited Loading

Overall issues:

VoiceOver + Chrome, MacOS

VoiceOver + Safari, Mac OS

VoiceOver + Safari, iOS

ChromeVox + Chrome, Dell Chromebook

JAWS 2019 + Chrome, Windows 10

NVDA + FireFox, Windows 10

Talkback + Chrome, Moto G6 Android V9

oliviertassinari commented Feb 10, 2020 • edited Loading

oliviertassinari Feb 10, 2020

Choose a reason for hiding this comment

oliviertassinari Feb 10, 2020

Choose a reason for hiding this comment

dmtrKovalenko commented Feb 10, 2020

oliviertassinari commented Feb 10, 2020

ahayes91 commented Feb 11, 2020 • edited Loading

attilavago commented Feb 11, 2020

dmtrKovalenko commented Feb 11, 2020

oliviertassinari commented Feb 11, 2020

dmtrKovalenko commented Feb 11, 2020

oliviertassinari commented Feb 11, 2020

dmtrKovalenko commented Feb 11, 2020

codecov bot commented Feb 13, 2020 • edited Loading

Codecov Report

dmtrKovalenko commented Feb 13, 2020

oliviertassinari commented Feb 14, 2020 • edited Loading

ahayes91 commented Sep 30, 2020

mhchen commented Dec 2, 2020

dmtrKovalenko commented Feb 10, 2020 •

edited

Loading

vercel bot commented Feb 10, 2020 •

edited

Loading

cypress bot commented Feb 10, 2020 •

edited

Loading

ahayes91 commented Feb 10, 2020 •

edited

Loading

oliviertassinari commented Feb 10, 2020 •

edited

Loading

ahayes91 commented Feb 11, 2020 •

edited

Loading

codecov bot commented Feb 13, 2020 •

edited

Loading

oliviertassinari commented Feb 14, 2020 •

edited

Loading