New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

react-datepicker is not accessible #1311

Open
afercia opened this Issue Jun 20, 2017 · 50 comments

Comments

Projects
None yet
@afercia
Contributor

afercia commented Jun 20, 2017

Looks like react-datepicker, currently used for the "publish" date, has several accessibility issues.

screen shot 2017-06-20 at 17 24 25

Just to mention a few:

  • not operable with a keyboard
  • empty and not focusable prev/next month links
  • day names not in relationship with the day numbers
  • arguable values for the day aria-labels, e.g. day-15
  • missing labels for the hour/minutes fields

I was also able to break it completely just editing the hour/mins fields using a keyboard:

screen shot 2017-06-15 at 14 51 02

I'd strongly recommend that every external component/library included in Gutenberg should be picked up taking into consideration also its accessibility support.

Not sure react-datepicker can be easily patched and made decently accessible. It would likely require a lot of work. Not sure if other, more accessible, react date-pickers exist. Not sure if using a date-picker is a good idea in the first place 🙁 Date pickers are always tricky.

One option could be considering a completely different UI, without a date-picker. Happy to evaluate other, more accessible, tools if any, but I'm afraid react-datepicker in its current state doesn't meet the quality standards we'd like to see in WordPress and it's a blocker for accessibility.

/cc @jasmussen and @joedolson (as he's an expert about calendars)

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jun 20, 2017

Contributor

Also to mention: AM/PM: not all countries in the world use them.

Contributor

afercia commented Jun 20, 2017

Also to mention: AM/PM: not all countries in the world use them.

@joedolson

This comment has been minimized.

Show comment
Hide comment
@joedolson

joedolson Jun 20, 2017

AM/PM would definitely get a lot of pushback and require a localized UI for alternate date/time formats.

I don't have a great solution for datepickers - they are truly difficult to make predictable. One solution I've favored is to allow manual string entry of dates and times, so that the datepicker is an optional UI; but even as an optional UI I would need it to be accessible; I'd just be less concerned about the complexity of the interaction patterns from the keyboard.

joedolson commented Jun 20, 2017

AM/PM would definitely get a lot of pushback and require a localized UI for alternate date/time formats.

I don't have a great solution for datepickers - they are truly difficult to make predictable. One solution I've favored is to allow manual string entry of dates and times, so that the datepicker is an optional UI; but even as an optional UI I would need it to be accessible; I'd just be less concerned about the complexity of the interaction patterns from the keyboard.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Jun 20, 2017

Member

Is there any use of date pickers elsewhere in the admin (I've assumed not), or an audit of available solutions and their accessibility?

In another of my own projects, I've integrated Flatpickr with React successfully, and know it is at least keyboard operable and opens in response to receiving focus, but on a cursory glance lacks some labeling.

Another option is to create a homegrown solution built with accessibility in mind.

Member

aduth commented Jun 20, 2017

Is there any use of date pickers elsewhere in the admin (I've assumed not), or an audit of available solutions and their accessibility?

In another of my own projects, I've integrated Flatpickr with React successfully, and know it is at least keyboard operable and opens in response to receiving focus, but on a cursory glance lacks some labeling.

Another option is to create a homegrown solution built with accessibility in mind.

@joedolson

This comment has been minimized.

Show comment
Hide comment
@joedolson

joedolson Jun 20, 2017

I can't recall running across a datepicker anywhere. The jQuery datepicker is something that's in the set of scripts bundled with WordPress by default, but I'm not aware of a core usage of it. I'm not sure of the current state of accessibility in that script, but it wasn't satisfactory when I last assessed it. That was over 2 years ago, however.

I've used Pickadate myself, but it's lacking any stable project maintainer at the moment, so probably not viable.

Here's the only information I know about accessible date pickers.

joedolson commented Jun 20, 2017

I can't recall running across a datepicker anywhere. The jQuery datepicker is something that's in the set of scripts bundled with WordPress by default, but I'm not aware of a core usage of it. I'm not sure of the current state of accessibility in that script, but it wasn't satisfactory when I last assessed it. That was over 2 years ago, however.

I've used Pickadate myself, but it's lacking any stable project maintainer at the moment, so probably not viable.

Here's the only information I know about accessible date pickers.

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jun 20, 2017

Contributor

The jQuery UI datepicker was recently properly localized, see https://core.trac.wordpress.org/changeset/37908. RTL support is also a concern. I'm not aware of any core usage, best persons to ask to: @ocean90 and @swissspidy

Contributor

afercia commented Jun 20, 2017

The jQuery UI datepicker was recently properly localized, see https://core.trac.wordpress.org/changeset/37908. RTL support is also a concern. I'm not aware of any core usage, best persons to ask to: @ocean90 and @swissspidy

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Jun 20, 2017

Contributor

AM/PM: not all countries in the world use them.

It's only activated depending on the time format defined in the general settings

Contributor

youknowriad commented Jun 20, 2017

AM/PM: not all countries in the world use them.

It's only activated depending on the time format defined in the general settings

@swissspidy

This comment has been minimized.

Show comment
Hide comment
@swissspidy

swissspidy Jun 20, 2017

Member

The jQuery UI datepicker is currently not used in core. It‘s only localized for plugins using it.

Member

swissspidy commented Jun 20, 2017

The jQuery UI datepicker is currently not used in core. It‘s only localized for plugins using it.

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jun 21, 2017

Contributor

Related discussions on core Trac:

Add jQuery UI's datepicker() where applicable
https://core.trac.wordpress.org/ticket/7665
(main discussion about jQuery UI's datepicker)

Use JS Calendar control for date picking
https://core.trac.wordpress.org/ticket/11942
(closed as duplicate but helpful to understand why at that time jQuery UI was not used)

Edit published date of post - inputs with no labels
https://core.trac.wordpress.org/ticket/25461
(more related to a11y)

Also to consider:

"Now" button for current date in update post published date and time
https://core.trac.wordpress.org/ticket/14364

Publish Date DatePicker
https://wordpress.org/plugins/publish-date-datepicker/
Plugin that adds the date picker to the UI

Contributor

afercia commented Jun 21, 2017

Related discussions on core Trac:

Add jQuery UI's datepicker() where applicable
https://core.trac.wordpress.org/ticket/7665
(main discussion about jQuery UI's datepicker)

Use JS Calendar control for date picking
https://core.trac.wordpress.org/ticket/11942
(closed as duplicate but helpful to understand why at that time jQuery UI was not used)

Edit published date of post - inputs with no labels
https://core.trac.wordpress.org/ticket/25461
(more related to a11y)

Also to consider:

"Now" button for current date in update post published date and time
https://core.trac.wordpress.org/ticket/14364

Publish Date DatePicker
https://wordpress.org/plugins/publish-date-datepicker/
Plugin that adds the date picker to the UI

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Aug 29, 2017

Contributor

Marking with the high priority label to indicate it's an a11y priority. At the very least, there should be an alternative way to enter a date using only a keyboard.

Contributor

afercia commented Aug 29, 2017

Marking with the high priority label to indicate it's an a11y priority. At the very least, there should be an alternative way to enter a date using only a keyboard.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Aug 29, 2017

Member

Couple options to consider:

Member

aduth commented Aug 29, 2017

Couple options to consider:

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Sep 6, 2017

Contributor

The react-dates component maintained by Airbnb claims by its description to be accessible

Maybe it's accessible, but it's announcing me the wrong month and days 😬 Maybe it's just a configuration issue. Hopefully. Not the best start, though.

screen shot 2017-09-06 at 17 33 10

I've run just a very quick, preliminar, test. I've navigated to a previous month (also, notice the color contrast on previous months is far from being accessible) but the wrong month/days are announced also on the initial view:

screen shot 2017-09-06 at 17 41 23

Contributor

afercia commented Sep 6, 2017

The react-dates component maintained by Airbnb claims by its description to be accessible

Maybe it's accessible, but it's announcing me the wrong month and days 😬 Maybe it's just a configuration issue. Hopefully. Not the best start, though.

screen shot 2017-09-06 at 17 33 10

I've run just a very quick, preliminar, test. I've navigated to a previous month (also, notice the color contrast on previous months is far from being accessible) but the wrong month/days are announced also on the initial view:

screen shot 2017-09-06 at 17 41 23

@jwold

This comment has been minimized.

Show comment
Hide comment
@jwold

jwold Sep 6, 2017

@afercia I'm curious if either if these datepickers would qualify as accessible:

  • Whatsock Date Picker (link)
  • Medium.com's date picker (the input field appears to be accessible, but the dropdown calendar is not) (screenshot)

jwold commented Sep 6, 2017

@afercia I'm curious if either if these datepickers would qualify as accessible:

  • Whatsock Date Picker (link)
  • Medium.com's date picker (the input field appears to be accessible, but the dropdown calendar is not) (screenshot)
@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Sep 6, 2017

Member

@jwold The latter of those two appears to be the browser-default <input type="date"> (specifically, Chrome's).

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

Member

aduth commented Sep 6, 2017

@jwold The latter of those two appears to be the browser-default <input type="date"> (specifically, Chrome's).

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Nov 8, 2017

Contributor

Sorry for the very late reply. The Whatsock Date Picker one, after an initial test, seems to work pretty well with keyboard and screen readers.

Contributor

afercia commented Nov 8, 2017

Sorry for the very late reply. The Whatsock Date Picker one, after an initial test, seems to work pretty well with keyboard and screen readers.

@jwold

This comment has been minimized.

Show comment
Hide comment
@jwold

jwold Nov 8, 2017

Thanks for the followup! Glad to hear that about the Whatsock Data Picker.

jwold commented Nov 8, 2017

Thanks for the followup! Glad to hear that about the Whatsock Data Picker.

@bph

This comment has been minimized.

Show comment
Hide comment
@bph

bph Mar 26, 2018

Contributor

Even for those just using a mouse it's not clear how to actually get out of the date picker. What is the action that makes it disappear after successfully picking a date: Is it the date? No. Is it the time? No. Is it the pm/am? No.

The only action that makes the date picker disappear and let's me continue with my work, is clicking outside the datepicker.

Contributor

bph commented Mar 26, 2018

Even for those just using a mouse it's not clear how to actually get out of the date picker. What is the action that makes it disappear after successfully picking a date: Is it the date? No. Is it the time? No. Is it the pm/am? No.

The only action that makes the date picker disappear and let's me continue with my work, is clicking outside the datepicker.

@karmatosed karmatosed modified the milestones: Merge Proposal, Merge Proposal: Accessibility Apr 12, 2018

@grahamarmfield

This comment has been minimized.

Show comment
Hide comment
@grahamarmfield

grahamarmfield Apr 13, 2018

+1 for the idea of not forcing people to use a date picker. Even if it were possible to find one that is accessible, it's a bit of an overhead for sighted keyboard users, and screen reader users.

Can we not use something similar to the publish date in the existing edit pages - a dropdown, plus text boxes, or something similar. Interacting with that would be a lot easier.

grahamarmfield commented Apr 13, 2018

+1 for the idea of not forcing people to use a date picker. Even if it were possible to find one that is accessible, it's a bit of an overhead for sighted keyboard users, and screen reader users.

Can we not use something similar to the publish date in the existing edit pages - a dropdown, plus text boxes, or something similar. Interacting with that would be a lot easier.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Apr 13, 2018

Member

a dropdown, plus text boxes, or something similar. Interacting with that would be a lot easier.

This may be subjective. I've personally found the classic editor's date inputs to be cumbersome to use contrasted with other date pickers I've used (web or otherwise).

Member

aduth commented Apr 13, 2018

a dropdown, plus text boxes, or something similar. Interacting with that would be a lot easier.

This may be subjective. I've personally found the classic editor's date inputs to be cumbersome to use contrasted with other date pickers I've used (web or otherwise).

@grahamarmfield

This comment has been minimized.

Show comment
Hide comment
@grahamarmfield

grahamarmfield Apr 13, 2018

How about making it an either/or option? So that people can use a date picker if they want to, but don't have to.

grahamarmfield commented Apr 13, 2018

How about making it an either/or option? So that people can use a date picker if they want to, but don't have to.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Apr 13, 2018

Member

How about making it an either/or option? So that people can use a date picker if they want to, but don't have to.

Seems to fall against the "Decisions, not Options" mantra.

It hasn't been raised but not addressed as of yet: How does <input type="date"> fare for accessibility and usability? That it's browser-dependent is a bit concerning, though it is native. We'd still need a separate field for time.

Member

aduth commented Apr 13, 2018

How about making it an either/or option? So that people can use a date picker if they want to, but don't have to.

Seems to fall against the "Decisions, not Options" mantra.

It hasn't been raised but not addressed as of yet: How does <input type="date"> fare for accessibility and usability? That it's browser-dependent is a bit concerning, though it is native. We'd still need a separate field for time.

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 14, 2018

Contributor

Note that I am reffering to the current state of the react-datepicker master branch, while an older version is being used in Guttenberg.

Currently, a keydown event listener is activated when a date field is focused with an active datepicker. The left and right arrow keys are used to navigate horizontally in the calendar (between weekdays) and hijacks the expected functionality of moving the text cursor within the field. Asking the user to hold down shift when pressing the arrow keys for the same functionality would eliminate the issue.

Modifying the keyboard navigation a bit and implementing aria-live on for the input field may go far with covering accessibility issues.

In the current master, tabbling out of the text field focuses on the next one, which I would consider to be expected behaviour.

I would say that as long as the date picker is not providing any additional navigable content and provides an editable text field as an alternative, I would go as far considering the datepicker to be extraneous content, according to WAI-ARIA. (Additional content in this case would be something like a price calendar for a flight booking system or a hairdresser's availability status for a given range of dates.)

Simply hiding a widget from assistive technologies such as screenreaders is allowed in this case:

Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.

(See: https://www.w3.org/TR/wai-aria-1.0/states_and_properties#aria-hidden)

I am exporing this aspect and may add it to react-datepicker, as a configurable property.

Contributor

aldavigdis commented Jun 14, 2018

Note that I am reffering to the current state of the react-datepicker master branch, while an older version is being used in Guttenberg.

Currently, a keydown event listener is activated when a date field is focused with an active datepicker. The left and right arrow keys are used to navigate horizontally in the calendar (between weekdays) and hijacks the expected functionality of moving the text cursor within the field. Asking the user to hold down shift when pressing the arrow keys for the same functionality would eliminate the issue.

Modifying the keyboard navigation a bit and implementing aria-live on for the input field may go far with covering accessibility issues.

In the current master, tabbling out of the text field focuses on the next one, which I would consider to be expected behaviour.

I would say that as long as the date picker is not providing any additional navigable content and provides an editable text field as an alternative, I would go as far considering the datepicker to be extraneous content, according to WAI-ARIA. (Additional content in this case would be something like a price calendar for a flight booking system or a hairdresser's availability status for a given range of dates.)

Simply hiding a widget from assistive technologies such as screenreaders is allowed in this case:

Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.

(See: https://www.w3.org/TR/wai-aria-1.0/states_and_properties#aria-hidden)

I am exporing this aspect and may add it to react-datepicker, as a configurable property.

@grahamarmfield

This comment has been minimized.

Show comment
Hide comment
@grahamarmfield

grahamarmfield Jun 15, 2018

@aldavigdis said:

I would say that as long as the date picker is not providing any additional navigable content and provides an editable text field as an alternative, I would go as far considering the datepicker to be extraneous content, according to WAI-ARIA. (Additional content in this case would be something like a price calendar for a flight booking system or a hairdresser's availability status for a given range of dates.).

Simply hiding a widget from assistive technologies such as screenreaders is allowed in this case:

I agree with that wholeheartedly. Even if it were possible to get all the labelling and keystrokes upstraight as per a reliable accessible pattern, date pickers can still be hard work for sighted keyboard users and screen reader users. I believe that most users in these groups would favour a plain text field (or fields) with proper labelling - labelling that includes the expected date format.

Have a button to show the date picker for those who like using them. Prob best to give that a suitable label too so that screen reader users know what it's for (and can avoid it).

grahamarmfield commented Jun 15, 2018

@aldavigdis said:

I would say that as long as the date picker is not providing any additional navigable content and provides an editable text field as an alternative, I would go as far considering the datepicker to be extraneous content, according to WAI-ARIA. (Additional content in this case would be something like a price calendar for a flight booking system or a hairdresser's availability status for a given range of dates.).

Simply hiding a widget from assistive technologies such as screenreaders is allowed in this case:

I agree with that wholeheartedly. Even if it were possible to get all the labelling and keystrokes upstraight as per a reliable accessible pattern, date pickers can still be hard work for sighted keyboard users and screen reader users. I believe that most users in these groups would favour a plain text field (or fields) with proper labelling - labelling that includes the expected date format.

Have a button to show the date picker for those who like using them. Prob best to give that a suitable label too so that screen reader users know what it's for (and can avoid it).

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Jun 15, 2018

Contributor

Solid updates, great comments, thanks so much.

Note that I am reffering to the current state of the react-datepicker master branch, while an older version is being used in Guttenberg.

Awesome!

Currently, a keydown event listener is activated when a date field is focused with an active datepicker. The left and right arrow keys are used to navigate horizontally in the calendar (between weekdays) and hijacks the expected functionality of moving the text cursor within the field. Asking the user to hold down shift when pressing the arrow keys for the same functionality would eliminate the issue.

Given I'm looking at the version in master, I may be missing something here, so forgive me if I am.

Could we inverse the behavior? I.e. allow arrow keys to do their standard left/right behavior in the date picker field, and allow maybe ⌘+left/right or some other modifier to allow navigating the dates?

Alternately could the left/right arrow keys to navigate the calendar be "disabled" if a textfield has focus? Or perhaps work when the parent element has focus? This is how the Block Library works in Gutenberg right now — click the Add Block button and the search field has focus, and arrow keys work fine. Tab to the next interface element, which is the Most Recent blocks panel, and arrow keys work to select the block you want.

I would say that as long as the date picker is not providing any additional navigable content and provides an editable text field as an alternative, I would go as far considering the datepicker to be extraneous content, according to WAI-ARIA.

... and ...

I agree with that wholeheartedly. Even if it were possible to get all the labelling and keystrokes upstraight as per a reliable accessible pattern, date pickers can still be hard work for sighted keyboard users and screen reader users. I believe that most users in these groups would favour a plain text field (or fields) with proper labelling - labelling that includes the expected date format.

👍 👍 I will always defer to the experts on this, so sounds good to me.

Is there a experimental branch where we can see the status?

Thanks so much! 🌟

Contributor

jasmussen commented Jun 15, 2018

Solid updates, great comments, thanks so much.

Note that I am reffering to the current state of the react-datepicker master branch, while an older version is being used in Guttenberg.

Awesome!

Currently, a keydown event listener is activated when a date field is focused with an active datepicker. The left and right arrow keys are used to navigate horizontally in the calendar (between weekdays) and hijacks the expected functionality of moving the text cursor within the field. Asking the user to hold down shift when pressing the arrow keys for the same functionality would eliminate the issue.

Given I'm looking at the version in master, I may be missing something here, so forgive me if I am.

Could we inverse the behavior? I.e. allow arrow keys to do their standard left/right behavior in the date picker field, and allow maybe ⌘+left/right or some other modifier to allow navigating the dates?

Alternately could the left/right arrow keys to navigate the calendar be "disabled" if a textfield has focus? Or perhaps work when the parent element has focus? This is how the Block Library works in Gutenberg right now — click the Add Block button and the search field has focus, and arrow keys work fine. Tab to the next interface element, which is the Most Recent blocks panel, and arrow keys work to select the block you want.

I would say that as long as the date picker is not providing any additional navigable content and provides an editable text field as an alternative, I would go as far considering the datepicker to be extraneous content, according to WAI-ARIA.

... and ...

I agree with that wholeheartedly. Even if it were possible to get all the labelling and keystrokes upstraight as per a reliable accessible pattern, date pickers can still be hard work for sighted keyboard users and screen reader users. I believe that most users in these groups would favour a plain text field (or fields) with proper labelling - labelling that includes the expected date format.

👍 👍 I will always defer to the experts on this, so sounds good to me.

Is there a experimental branch where we can see the status?

Thanks so much! 🌟

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 16, 2018

Contributor

Have a button to show the date picker for those who like using them. Prob best to give that a suitable label too so that screen reader users know what it's for (and can avoid it).

Perhaps there should be a user_meta option in Gutenberg to enable/disable the date picker?

Interesting point of view regarding making it more compatible with how Gutenberg works.

Could we inverse the behavior? I.e. allow arrow keys to do their standard left/right behavior in the date picker field, and allow maybe ⌘+left/right or some other modifier to allow navigating the dates?

It's actually really, really tricky to get something like this right. ctrl and arrow keys is bound to an OS-level function on Mac OS X, so even if the browser does event.preventDefault(), the OS doesn't care, and frankly, not all the keys relied on in react-datepicker are on many modern keyboards (PgDn, Home etc.)

I still think I managed to find a middle ground here while making the time picker part keyboard navigable.

Anyway — in my experimental branch, I elected for having a div, refferred to by aria-describedby. That div is hidden using CSS for now, but could be changed to a tooltip or something similar, but I think it's not the role of react-datepicker, but something that should be done in the implementation (in our case, in Gutenberg itself), as I think as a simple React component, its default behavour should be as simple as possible.

👍 👍 I will always defer to the experts on this, so sounds good to me.

Any input helps! We better ask all the questions first and it helps turn all stones, which is important here. I'm very happy to see @grahamarmfield stepping in.

Is there a experimental branch where we can see the status?

I'll post it here by the end of this day (Saturday). I already have a fork on my GitHub account and I want to spend some time on writing the commit messages. Feel free to get in touch on Slack or something if you want to schedule a demo @jasmussen.

It would be great to get to finish this before the ticket lives its first anniversary. 🎂

Thanks a lot for the input @grahamarmfield and @jasmussen.

Contributor

aldavigdis commented Jun 16, 2018

Have a button to show the date picker for those who like using them. Prob best to give that a suitable label too so that screen reader users know what it's for (and can avoid it).

Perhaps there should be a user_meta option in Gutenberg to enable/disable the date picker?

Interesting point of view regarding making it more compatible with how Gutenberg works.

Could we inverse the behavior? I.e. allow arrow keys to do their standard left/right behavior in the date picker field, and allow maybe ⌘+left/right or some other modifier to allow navigating the dates?

It's actually really, really tricky to get something like this right. ctrl and arrow keys is bound to an OS-level function on Mac OS X, so even if the browser does event.preventDefault(), the OS doesn't care, and frankly, not all the keys relied on in react-datepicker are on many modern keyboards (PgDn, Home etc.)

I still think I managed to find a middle ground here while making the time picker part keyboard navigable.

Anyway — in my experimental branch, I elected for having a div, refferred to by aria-describedby. That div is hidden using CSS for now, but could be changed to a tooltip or something similar, but I think it's not the role of react-datepicker, but something that should be done in the implementation (in our case, in Gutenberg itself), as I think as a simple React component, its default behavour should be as simple as possible.

👍 👍 I will always defer to the experts on this, so sounds good to me.

Any input helps! We better ask all the questions first and it helps turn all stones, which is important here. I'm very happy to see @grahamarmfield stepping in.

Is there a experimental branch where we can see the status?

I'll post it here by the end of this day (Saturday). I already have a fork on my GitHub account and I want to spend some time on writing the commit messages. Feel free to get in touch on Slack or something if you want to schedule a demo @jasmussen.

It would be great to get to finish this before the ticket lives its first anniversary. 🎂

Thanks a lot for the input @grahamarmfield and @jasmussen.

aldavigdis added a commit to aldavigdis/react-datepicker that referenced this issue Jun 16, 2018

Improving accessibility
* Improving keyboard navigation. Now works with time picker too.
* Shorthand weekday names are now displayed as `abbr` tags, with full names as title.
* Using a colour with higher contrast for month navigation.
* Adding a WAI-ARIA compatible description.
* The text field now has `aria-live="polite"`, which should update screenreader users as soon as the value changes.
* The date picker popper now has the `aria-hidden` tag, making it invisible to screenreaders and assistive technologies, in order to make navigation more straightforward.

Detailed discussion at WordPress/gutenberg#1311
@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 16, 2018

Contributor

I've pushed the changes I've made — and to quote the ARIA description box regarding keyboard navigation:

  • Use Shift + Left Arrow or Shift + Right Arrow to navigate between weekdays.
  • Shift + Up or Down Arrow to navigate between weeks.
  • Up and Down Arrow navigate between time intervals.
  • Page Up and Page Down naviagte between months. End and Home navigate between years.
  • Press enter to select the highlighted date and time.

Ergo, the user now needs to hold down shift to navigate within the calendar, as navigating horizontally would break the expected behaviour of input boxes. Pressing up and down directly navigates within the time picker instead now (which is a new feature that was a bit tricky to implement).

The changeset is at aldavigdis/react-datepicker@768dcea, but do expect me to do a force push a couple of times today as there are some broken tests and typoes — and I haven't run eslint yet.

Contributor

aldavigdis commented Jun 16, 2018

I've pushed the changes I've made — and to quote the ARIA description box regarding keyboard navigation:

  • Use Shift + Left Arrow or Shift + Right Arrow to navigate between weekdays.
  • Shift + Up or Down Arrow to navigate between weeks.
  • Up and Down Arrow navigate between time intervals.
  • Page Up and Page Down naviagte between months. End and Home navigate between years.
  • Press enter to select the highlighted date and time.

Ergo, the user now needs to hold down shift to navigate within the calendar, as navigating horizontally would break the expected behaviour of input boxes. Pressing up and down directly navigates within the time picker instead now (which is a new feature that was a bit tricky to implement).

The changeset is at aldavigdis/react-datepicker@768dcea, but do expect me to do a force push a couple of times today as there are some broken tests and typoes — and I haven't run eslint yet.

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 16, 2018

Contributor

So, I'm keeping the PgUp/PgDn and End/Home functionality, sans the shift key. It could be replaced with more complex modifier key combinations, but I guess people with less than four arms/tentales may be at a disatvantage there.

Contributor

aldavigdis commented Jun 16, 2018

So, I'm keeping the PgUp/PgDn and End/Home functionality, sans the shift key. It could be replaced with more complex modifier key combinations, but I guess people with less than four arms/tentales may be at a disatvantage there.

aldavigdis added a commit to aldavigdis/react-datepicker that referenced this issue Jun 18, 2018

Improving accessibility
* Improving keyboard navigation. Now works with time picker too.
* Shorthand weekday names are now displayed as `abbr` tags, with full names as title.
* Using a colour with higher contrast for month navigation.
* Adding a WAI-ARIA compatible description.
* The text field now has `aria-live="polite"`, which should update screenreader users as soon as the value changes.
* The date picker popper now has the `aria-hidden` tag, making it invisible to screenreaders and assistive technologies, in order to make navigation more straightforward.

Detailed discussion at WordPress/gutenberg#1311

aldavigdis added a commit to aldavigdis/react-datepicker that referenced this issue Jun 18, 2018

Improving accessibility
* Improving keyboard navigation. Now works with time picker too.
* Shorthand weekday names are now displayed as `abbr` tags, with full names as title.
* Using a colour with higher contrast for month navigation.
* Adding a WAI-ARIA compatible description.
* The text field now has `aria-live="polite"`, which should update screenreader users as soon as the value changes.
* The date picker popper now has the `aria-hidden` tag, making it invisible to screenreaders and assistive technologies, in order to make navigation more straightforward.

Detailed discussion at WordPress/gutenberg#1311
@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jun 18, 2018

Contributor

@aldavigdis thanks very much for diving into this, very appreciated.

Worth considering the date picker used in Gutenberg is set up as the "inline version" example, see https://reactdatepicker.com/#example-36 that means there's no input field. Even if we change the configuration to add the input field, then the keydown event (which is attached to the input field...) would kick in producing the conflicts you mentioned above. Allowing the left and right arrow keys to operate normally is a first step but then we should also allow other native, standard, key strokes that normally work within input fields, like home and end (e.g. Cmd + left/right on a mac), partial selection (e.g. Shift+Alt+left/right on a mac) etc. I guess that would be a bit complicated, as the root issue here is react-datepicker is inherently flawed as it alters native interaction with the input field.

Regardless, even if we're successful in improving a bit keyboard interaction, there are many other accessibility issues, especially when assistive technologies come into play. For example, the keydown event works with screen readers on Windows because, as soon as they encounter the input field, they switch to "forms mode" and stop intercepting key strokes. However, the calendar semantics is far from ideal and basically nothing useful is announced to screen reader users. Similar problems would be faced by speech recognition software users as well, as some UI controls are completely unlabelled. Even if the controls were labelled, their name should be visually apparent in some way to allow users to properly voice a command.

Overall, react-datepicker should be largely refactored to get to a minimum, decent, accessibility level and I'm not sure what the final result would be anyway.

Some screenshots after testing on Windows, with both the NVDA and JAWS screen readers:

  • the previous and next buttons are unlabelled and announced just as "button"
  • tabbing skips the whole calendar and jumps to the time fields
  • the time fields are unlabelled, only their value is announced
  • the AM/PM buttons could benefit from some more meaningful text

screenshot 30

  • using arrow keys with a screen reader allows to explore the calendar content
  • the day names are just a 2 letters abbreviation, so screen readers don't get they're days (I 3-letters abbreviations would work better, e.g. Mon, Tue, Wed, etc.); right now, the day names are announced all together like it was a unique word, something like soo-mo-too-wee-t-aitch-ef-ar-sa

screenshot 31

  • the days in the calendar are announced as list because they use the ARIA roles listbox and option, which replicates the semantics of a <select> element
  • unfortunately, the list is perceived by both NVDA and JAWS as an empty list, as the options are expected to be first child of the listbox element, so nothing is announced
  • the days use an aria-label attribute, e.g. aria-label="day-1" I'd argue that's not so beneficial but, regardless, nothing is announced because of the previous issue

screenshot 32

  • even on the official demo, where the input field and arrows navigation through the days work, nothing is read out: screen readers announced just "blank" when a day is highlighted as DOM focus is on the input field and there's really no reason why they should announce the days (unless the whole calendar gets refactored as sort of an ARIA combobox)

screenshot 33

I'd still tend to think the best option to make the publish date UI usable by everyone would be using a simple input field with a suggested date format (the format should change based on the user locale). This input field should be completely separated by the one used by react-datepicker so as to keep intact native interaction. Then, the time input fields could follow and after them, for users who prefer to use the date picker and are able to use it, a button could reveal the date-picker interface. I'd totally agree on trying to find a way to completely hide the "picker" UI from assistive technologies.

Besides the a11y issues, I've noticed a couple of functional issues, /Cc @mtias @aduth etc. 🙂

  • WordPress has a start_of_week option in the general settings, changing that I don't see any change in the datepicker UI: the first column is always "Sunday". At a quick first glance, seems to me react-datepicker bases this on the locale instead of a specific setting
  • changing user locale, just some parts of the UI get translated, not sure how the translations work on react-datepicker (see screenshot below). The day columns are always in English, not to mention the aria-labels (day and week) are not translatable because part of the string is in English and hardcoded:
aria-label={`day-${getDate(this.props.day)}`}
aria-label={`week-${this.props.weekNumber}`}

Please let me know if I should open separate issues.

screen shot 2018-06-18 at 14 16 11

Contributor

afercia commented Jun 18, 2018

@aldavigdis thanks very much for diving into this, very appreciated.

Worth considering the date picker used in Gutenberg is set up as the "inline version" example, see https://reactdatepicker.com/#example-36 that means there's no input field. Even if we change the configuration to add the input field, then the keydown event (which is attached to the input field...) would kick in producing the conflicts you mentioned above. Allowing the left and right arrow keys to operate normally is a first step but then we should also allow other native, standard, key strokes that normally work within input fields, like home and end (e.g. Cmd + left/right on a mac), partial selection (e.g. Shift+Alt+left/right on a mac) etc. I guess that would be a bit complicated, as the root issue here is react-datepicker is inherently flawed as it alters native interaction with the input field.

Regardless, even if we're successful in improving a bit keyboard interaction, there are many other accessibility issues, especially when assistive technologies come into play. For example, the keydown event works with screen readers on Windows because, as soon as they encounter the input field, they switch to "forms mode" and stop intercepting key strokes. However, the calendar semantics is far from ideal and basically nothing useful is announced to screen reader users. Similar problems would be faced by speech recognition software users as well, as some UI controls are completely unlabelled. Even if the controls were labelled, their name should be visually apparent in some way to allow users to properly voice a command.

Overall, react-datepicker should be largely refactored to get to a minimum, decent, accessibility level and I'm not sure what the final result would be anyway.

Some screenshots after testing on Windows, with both the NVDA and JAWS screen readers:

  • the previous and next buttons are unlabelled and announced just as "button"
  • tabbing skips the whole calendar and jumps to the time fields
  • the time fields are unlabelled, only their value is announced
  • the AM/PM buttons could benefit from some more meaningful text

screenshot 30

  • using arrow keys with a screen reader allows to explore the calendar content
  • the day names are just a 2 letters abbreviation, so screen readers don't get they're days (I 3-letters abbreviations would work better, e.g. Mon, Tue, Wed, etc.); right now, the day names are announced all together like it was a unique word, something like soo-mo-too-wee-t-aitch-ef-ar-sa

screenshot 31

  • the days in the calendar are announced as list because they use the ARIA roles listbox and option, which replicates the semantics of a <select> element
  • unfortunately, the list is perceived by both NVDA and JAWS as an empty list, as the options are expected to be first child of the listbox element, so nothing is announced
  • the days use an aria-label attribute, e.g. aria-label="day-1" I'd argue that's not so beneficial but, regardless, nothing is announced because of the previous issue

screenshot 32

  • even on the official demo, where the input field and arrows navigation through the days work, nothing is read out: screen readers announced just "blank" when a day is highlighted as DOM focus is on the input field and there's really no reason why they should announce the days (unless the whole calendar gets refactored as sort of an ARIA combobox)

screenshot 33

I'd still tend to think the best option to make the publish date UI usable by everyone would be using a simple input field with a suggested date format (the format should change based on the user locale). This input field should be completely separated by the one used by react-datepicker so as to keep intact native interaction. Then, the time input fields could follow and after them, for users who prefer to use the date picker and are able to use it, a button could reveal the date-picker interface. I'd totally agree on trying to find a way to completely hide the "picker" UI from assistive technologies.

Besides the a11y issues, I've noticed a couple of functional issues, /Cc @mtias @aduth etc. 🙂

  • WordPress has a start_of_week option in the general settings, changing that I don't see any change in the datepicker UI: the first column is always "Sunday". At a quick first glance, seems to me react-datepicker bases this on the locale instead of a specific setting
  • changing user locale, just some parts of the UI get translated, not sure how the translations work on react-datepicker (see screenshot below). The day columns are always in English, not to mention the aria-labels (day and week) are not translatable because part of the string is in English and hardcoded:
aria-label={`day-${getDate(this.props.day)}`}
aria-label={`week-${this.props.weekNumber}`}

Please let me know if I should open separate issues.

screen shot 2018-06-18 at 14 16 11

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 20, 2018

Contributor

Worth considering the date picker used in Gutenberg is set up as the "inline version" example, see https://reactdatepicker.com/#example-36 that means there's no input field.

This is something I want to tackle in Gutenberg itself. Thanks a lot for bringing this to my attention, as this will be the next step in solving this ticket.

One solution may be to simply trigger the visibility of an actual <input> element when this <a> element is clicked. But as noted, that needs to happen within Gutenberg itself, not in React-Datepicker.

Allowing the left and right arrow keys to operate normally is a first step but then we should also allow other native, standard, key strokes that normally work within input fields, like home and end (e.g. Cmd + left/right on a mac), partial selection (e.g. Shift+Alt+left/right on a mac) etc.

I decided to utilise shift as a modifier key for navigating the calendar. This includes the functionality of Home, End, PageUp and PageDown. Alt and CMD/ctrl are often tied to OS-level functionality when used with arrow keys.

However, the calendar semantics is far from ideal and basically nothing useful is announced to screen reader users.

I added relevant WAI-ARIA tags and I do hope that will solve some of the issues you are describing here. This includes aria-live for the input field, to announce changes. If an input field is not used by Gutenberg, then that tag could be added to implement that functionality.

As my approach to polyfills is to move them away from the screenreader users and to allow for form elements to be filled manually, I have also added aria-hidden to the calendar popper, which takes the datepicker itself out of the screenreader context. (Oh, wait — that brings up a new problem, if there is no actual input field in use, but I may have a solution.)

the previous and next buttons are unlabelled and announced just as "button"

I added content to those buttons, which can be set using the navigationNextText and navigationPreviousText. The default value is Next month and Previous month. I have also improved the contrast those buttons had with the white background.

tabbing skips the whole calendar and jumps to the time fields

In the current version of React-Datepicker, the time is displayed using a list on the right-hand side of the calendar. My approach here is to allow users to tab out of the text field and into the next one. Keyboard navigation will also work with the time selector, so it may cover the issue.

the day names are just a 2 letters abbreviation

I have attempted to fix this by creating <abbr> tags with the full date name as the title. After going over this, I may want to add text nodes here with nothing but a space in them to simulate separation as the calendar is rendered using a collection of <div> elements, instead of being a <table>.

A fundamental (and a really annoying) problem with React-Datepicker is the fact that the calendars are not treated as tabular data. The date pickers I've worked on in the past have generally used <table> elements for the calendar itself, with a <thead> with <th> elements as the list of weekdays.

Regardless, as the date picker is no longer visible to screen readers in the current PR, this may be redunant. I still want to explore the option to make the visibility optional, but this requires snaking through a chain of React components. I may add this to a separate PR to React-Datepicker.

Besides the a11y issues, I've noticed a couple of functional issues […]

Sounds like something that should be added as a separate issue ticket. Perhaps reffering this ticket would be a good idea too, so I could work on it after this one (given the capacity of course).


Furthermore, I know there was some dicussion about this on Slack, but unfortunatly, I wasn't there, with the reason being I need to migrate to a new WordPress.org user before joining there again, so I can keep a consitent username and apperiance on all communication channels.

Contributor

aldavigdis commented Jun 20, 2018

Worth considering the date picker used in Gutenberg is set up as the "inline version" example, see https://reactdatepicker.com/#example-36 that means there's no input field.

This is something I want to tackle in Gutenberg itself. Thanks a lot for bringing this to my attention, as this will be the next step in solving this ticket.

One solution may be to simply trigger the visibility of an actual <input> element when this <a> element is clicked. But as noted, that needs to happen within Gutenberg itself, not in React-Datepicker.

Allowing the left and right arrow keys to operate normally is a first step but then we should also allow other native, standard, key strokes that normally work within input fields, like home and end (e.g. Cmd + left/right on a mac), partial selection (e.g. Shift+Alt+left/right on a mac) etc.

I decided to utilise shift as a modifier key for navigating the calendar. This includes the functionality of Home, End, PageUp and PageDown. Alt and CMD/ctrl are often tied to OS-level functionality when used with arrow keys.

However, the calendar semantics is far from ideal and basically nothing useful is announced to screen reader users.

I added relevant WAI-ARIA tags and I do hope that will solve some of the issues you are describing here. This includes aria-live for the input field, to announce changes. If an input field is not used by Gutenberg, then that tag could be added to implement that functionality.

As my approach to polyfills is to move them away from the screenreader users and to allow for form elements to be filled manually, I have also added aria-hidden to the calendar popper, which takes the datepicker itself out of the screenreader context. (Oh, wait — that brings up a new problem, if there is no actual input field in use, but I may have a solution.)

the previous and next buttons are unlabelled and announced just as "button"

I added content to those buttons, which can be set using the navigationNextText and navigationPreviousText. The default value is Next month and Previous month. I have also improved the contrast those buttons had with the white background.

tabbing skips the whole calendar and jumps to the time fields

In the current version of React-Datepicker, the time is displayed using a list on the right-hand side of the calendar. My approach here is to allow users to tab out of the text field and into the next one. Keyboard navigation will also work with the time selector, so it may cover the issue.

the day names are just a 2 letters abbreviation

I have attempted to fix this by creating <abbr> tags with the full date name as the title. After going over this, I may want to add text nodes here with nothing but a space in them to simulate separation as the calendar is rendered using a collection of <div> elements, instead of being a <table>.

A fundamental (and a really annoying) problem with React-Datepicker is the fact that the calendars are not treated as tabular data. The date pickers I've worked on in the past have generally used <table> elements for the calendar itself, with a <thead> with <th> elements as the list of weekdays.

Regardless, as the date picker is no longer visible to screen readers in the current PR, this may be redunant. I still want to explore the option to make the visibility optional, but this requires snaking through a chain of React components. I may add this to a separate PR to React-Datepicker.

Besides the a11y issues, I've noticed a couple of functional issues […]

Sounds like something that should be added as a separate issue ticket. Perhaps reffering this ticket would be a good idea too, so I could work on it after this one (given the capacity of course).


Furthermore, I know there was some dicussion about this on Slack, but unfortunatly, I wasn't there, with the reason being I need to migrate to a new WordPress.org user before joining there again, so I can keep a consitent username and apperiance on all communication channels.

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 20, 2018

Contributor

I'll dive into the Gutenberg codebase by tomorrow. Will also install a proper screenreader on a Windows partition to explore more things.

Contributor

aldavigdis commented Jun 20, 2018

I'll dive into the Gutenberg codebase by tomorrow. Will also install a proper screenreader on a Windows partition to explore more things.

@afercia

This comment has been minimized.

Show comment
Hide comment
@afercia

afercia Jun 20, 2018

Contributor

@aldavigdis thanks so much.

I added relevant WAI-ARIA tags and I do hope that will solve some of the issues you are describing here. This includes aria-live for the input field, to announce changes.

Maybe I'm missing something but if we hide the whole date picker from assistive technologies then why to use aria-live on the input field? Ideally the input field should behave in a native way, its value would be read out when tabbing into it (content gets selected automatically ) or when typing, character by character.

In the current version of React-Datepicker, the time is displayed using a list on the right-hand side of the calendar. My approach here is to allow users to tab out of the text field and into the next one. Keyboard navigation will also work with the time selector, so it may cover the issue.

Yep, I've seen the list on the right, however in Gutenberg the time fields are implemented differently:

screen shot 2018-06-20 at 08 53 50

A fundamental (and a really annoying) problem with React-Datepicker is the fact that the calendars are not treated as tabular data.

Yeah... there's no programmatic relationship between days and numbers, however as you said this may be pointless if we hide the whole calendar from assistive technologies.

Thanks again, looking forward to see the improvements.

Contributor

afercia commented Jun 20, 2018

@aldavigdis thanks so much.

I added relevant WAI-ARIA tags and I do hope that will solve some of the issues you are describing here. This includes aria-live for the input field, to announce changes.

Maybe I'm missing something but if we hide the whole date picker from assistive technologies then why to use aria-live on the input field? Ideally the input field should behave in a native way, its value would be read out when tabbing into it (content gets selected automatically ) or when typing, character by character.

In the current version of React-Datepicker, the time is displayed using a list on the right-hand side of the calendar. My approach here is to allow users to tab out of the text field and into the next one. Keyboard navigation will also work with the time selector, so it may cover the issue.

Yep, I've seen the list on the right, however in Gutenberg the time fields are implemented differently:

screen shot 2018-06-20 at 08 53 50

A fundamental (and a really annoying) problem with React-Datepicker is the fact that the calendars are not treated as tabular data.

Yeah... there's no programmatic relationship between days and numbers, however as you said this may be pointless if we hide the whole calendar from assistive technologies.

Thanks again, looking forward to see the improvements.

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 20, 2018

Contributor

this may be pointless if we hide the whole calendar from assistive technologies.

I like to hope this is just the beginning of further improvement of the library. My contract is expiring really soon and after I realised converting the calendars to being laid out as tables would be the most appropriate way of making the date picker itself "sustainable", I also realised it would be a very time consuming process as well.

I'll be examining the implementation in Gutenberg more closely today and once I've finally made a pull request on here, I would like to bring my attention to the HTML semantics of React-Datepicker insha'Allah.

Contributor

aldavigdis commented Jun 20, 2018

this may be pointless if we hide the whole calendar from assistive technologies.

I like to hope this is just the beginning of further improvement of the library. My contract is expiring really soon and after I realised converting the calendars to being laid out as tables would be the most appropriate way of making the date picker itself "sustainable", I also realised it would be a very time consuming process as well.

I'll be examining the implementation in Gutenberg more closely today and once I've finally made a pull request on here, I would like to bring my attention to the HTML semantics of React-Datepicker insha'Allah.

@grahamarmfield

This comment has been minimized.

Show comment
Hide comment
@grahamarmfield

grahamarmfield Jun 20, 2018

Replying to @aldavigdis.

Whilst using the tag with title on the day names to indicate an abbreviation should be a good answer, the reality is that screen reader support for is patchy. I did a (less than) scientific survey for this blog post: https://openinclusion.com/blog/presenting-abbreviations-acronyms-for-screen-reader-users/

You also talk about the desirability of having each month marked up as a table. I think that's right, but having elements as column headers is going a bit extra. We'd need to test how that worked...

grahamarmfield commented Jun 20, 2018

Replying to @aldavigdis.

Whilst using the tag with title on the day names to indicate an abbreviation should be a good answer, the reality is that screen reader support for is patchy. I did a (less than) scientific survey for this blog post: https://openinclusion.com/blog/presenting-abbreviations-acronyms-for-screen-reader-users/

You also talk about the desirability of having each month marked up as a table. I think that's right, but having elements as column headers is going a bit extra. We'd need to test how that worked...

@grahamarmfield

This comment has been minimized.

Show comment
Hide comment
@grahamarmfield

grahamarmfield Jun 20, 2018

My comment rendered slightly less easy to understand by HTML being stripped out - apologies.

The missing word is abbr - both times.

grahamarmfield commented Jun 20, 2018

My comment rendered slightly less easy to understand by HTML being stripped out - apologies.

The missing word is abbr - both times.

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 21, 2018

Contributor

I am honestly starting to think that implementing drop-down menus instead of an athetiscally pleasing date picker is the best way to get this right.

Contributor

aldavigdis commented Jun 21, 2018

I am honestly starting to think that implementing drop-down menus instead of an athetiscally pleasing date picker is the best way to get this right.

@grahamarmfield

This comment has been minimized.

Show comment
Hide comment
@grahamarmfield

grahamarmfield Jun 22, 2018

@aldavigdis said:

I am honestly starting to think that implementing drop-down menus instead of an athetiscally pleasing date picker is the best way to get this right.

Perhaps I'm biased after accessibility auditing so many sites, and seeing people trying to use them, but I'm having problems with seeing date pickers as pleasing in any way.

Seriously though, having 3 dropdowns or text boxes for date, and 2 for time is going to be a lot easier a) to implement and b) to use for many people.

The current editor defaults to publish immediately, and only shows dropdowns and text boxes if I wish to edit that. Then the values default to 'now'. There's an OK button which then 'fixes' the publish date/time.

Can we not use the same model in Gutenberg?

grahamarmfield commented Jun 22, 2018

@aldavigdis said:

I am honestly starting to think that implementing drop-down menus instead of an athetiscally pleasing date picker is the best way to get this right.

Perhaps I'm biased after accessibility auditing so many sites, and seeing people trying to use them, but I'm having problems with seeing date pickers as pleasing in any way.

Seriously though, having 3 dropdowns or text boxes for date, and 2 for time is going to be a lot easier a) to implement and b) to use for many people.

The current editor defaults to publish immediately, and only shows dropdowns and text boxes if I wish to edit that. Then the values default to 'now'. There's an OK button which then 'fixes' the publish date/time.

Can we not use the same model in Gutenberg?

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 24, 2018

Contributor

We are on the same page here @grahamarmfield.

Perhaps I'm biased after accessibility auditing so many sites, and seeing people trying to use them, but I'm having problems with seeing date pickers as pleasing in any way.

You are absolutely correct here.

Having dug very deep into this, I am getting to the conclusion that date pickers, while perhaps asthetically pleasing are not very useful, unless they provide additional functionality. The WAI working group has even removed any references to date pickers from their current version of the WAI-ARIA Best Practices document.

Unfortunatly, a lot of other information I have gathered uses the outdated version as a primary reference.

While date pickers may provide visual cues, I can conclude they should only be used as a seccondary option, after proper forms and input fields.

Seriously though, having 3 dropdowns or text boxes for date, and 2 for time is going to be a lot easier a) to implement and b) to use for many people.

This is what I have concluded too. Having input fields with proper labels, just as in the classic WordPress editor should be good enough.

The current editor defaults to publish immediately, and only shows dropdowns and text boxes if I wish to edit that. Then the values default to 'now'. There's an OK button which then 'fixes' the publish date/time.

My mistake was to assume the main issue was with how the date picker widget itslef operated internally. In other words, assuming that the main issue was with the React-Datepicker library, but not how it was implemented in Gutenberg and Calypso.

In essence, what I'd like to do is to use form fields by default. I am okay with displaying a date picker along with that as a visual indicator, but keeping it outside of the screenreader context and tab index.

What I have done with React-Datepicker is really only a stop-gap measure.

I did a write-up on this, which is available as a blog post at https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/.

I will see if I can keep on working on this into this week. But it also means I need to ballance this with some contract work.

Contributor

aldavigdis commented Jun 24, 2018

We are on the same page here @grahamarmfield.

Perhaps I'm biased after accessibility auditing so many sites, and seeing people trying to use them, but I'm having problems with seeing date pickers as pleasing in any way.

You are absolutely correct here.

Having dug very deep into this, I am getting to the conclusion that date pickers, while perhaps asthetically pleasing are not very useful, unless they provide additional functionality. The WAI working group has even removed any references to date pickers from their current version of the WAI-ARIA Best Practices document.

Unfortunatly, a lot of other information I have gathered uses the outdated version as a primary reference.

While date pickers may provide visual cues, I can conclude they should only be used as a seccondary option, after proper forms and input fields.

Seriously though, having 3 dropdowns or text boxes for date, and 2 for time is going to be a lot easier a) to implement and b) to use for many people.

This is what I have concluded too. Having input fields with proper labels, just as in the classic WordPress editor should be good enough.

The current editor defaults to publish immediately, and only shows dropdowns and text boxes if I wish to edit that. Then the values default to 'now'. There's an OK button which then 'fixes' the publish date/time.

My mistake was to assume the main issue was with how the date picker widget itslef operated internally. In other words, assuming that the main issue was with the React-Datepicker library, but not how it was implemented in Gutenberg and Calypso.

In essence, what I'd like to do is to use form fields by default. I am okay with displaying a date picker along with that as a visual indicator, but keeping it outside of the screenreader context and tab index.

What I have done with React-Datepicker is really only a stop-gap measure.

I did a write-up on this, which is available as a blog post at https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/.

I will see if I can keep on working on this into this week. But it also means I need to ballance this with some contract work.

@aldavigdis

This comment has been minimized.

Show comment
Hide comment
@aldavigdis

aldavigdis Jun 28, 2018

Contributor

Dear all — a pull request has been submitted based on this issue ticket: #7621

Contributor

aldavigdis commented Jun 28, 2018

Dear all — a pull request has been submitted based on this issue ticket: #7621

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment