Date values in the datepicker are not fully parsed

[karlgroves]

Date values in the datepicker are not fully parsed

• Severity: High
• Affected Populations:
  • Blind
  • Low-Vision
  • Cognitively Impaired
• Platform(s):
  • Windows - Screen Reader
  • Mac - VoiceOver
  • Android - TalkBack
  • iOS - VoiceOver
• Components affected:
  • Document Panel
  • Publish and Unpublish

Issue description

When navigating through the datepicker using a screen reader, the
current date is announced as (for example) "Tuesday, F j, 2019" rather
than "Tuesday, January 15, 2019".

These same "F j" tokens are present in all the aria-label
attributes within the date picker.

This is almost certainly a technical problem, whereby date tokens are
not being parsed into their equivalent language.

Issue Code

    <tr>


       <td tabindex="-1" class="..." role="button" style="width: 30px; height: 29px;" aria-label="Tuesday, F j, 2019">15</td>


       <td tabindex="-1" class="..." role="button" style="..." aria-label="Wednesday, F j, 2019">16</td>


       ...


    </tr>

Remediation Guidance

Ensure that all date tokens are parsed into their equivalent language.

Recommended Code

    <tr>


       <td tabindex="-1" class="..." role="button" style="width: 30px; height: 29px;" aria-label="Tuesday,  January 15, 2019">15</td>


       <td tabindex="-1" class="..." role="button" style="..." aria-label="Wednesday, January 16, 2019">16</td>


       ...


    </tr>

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-12 in Tenon's report

[afercia]

Screenshot testing with Firefox and NVDA:

[sabernhardt]

I can't seem to find a fix for the parsing, yet there are other requests to add after some investigation:

1. Format date based on user's language.

The unparsed format "F j" comes from the default U.S. English site-wide Date Format (date_format) setting. It could be better to use the individual user's language setting for the locale.

Currently, the year is parsed correctly and the day of the week is in the user's language. However, the month and date are wrong. If the Date Format uses month names, the label simply does not parse "F j" (or "j F" for the day before the month).

Or if I set the site's Date Format to match 6/21/2019 (m/d/Y), it gives me the same set of ARIA labels for each week (of the same year):

Monday, 0/1/2019
Tuesday, 0/2/2019
Wednesday, 0/3/2019
Thursday, 0/4/2019
Friday, 0/5/2019
Saturday, 0/6/2019
Sunday, 0/0/2019

2. Use translatable text strings.

"Selected" is coded specifically in English instead of using a translatable string:

var dateIsSelected = function dateIsSelected(_ref5) {
  var date = _ref5.date;
  return 'Selected. ' + String(date);
};

[afercia]

This also depends on the Date/Time setting users set under "General Settings" in the admin. For example

With:
Date: F j, Y
Time: g:i a
the result is:
aria-label="Monday, F j, 2019"

With:
Date: d/m/Y
Time: H:i
the result is:
aria-label="Monday, 1/0/2019"

This issue is still waiting for a fix since almost a year Gutenberg was released, it would be great to give it a bit more high priority.

[sabernhardt]

Could the aria-label attribute be removed, as a simple/temporary solution?

The "button" text itself already gives the correct day of the month. While that's not as valuable as a full date, it should be better than the currently incorrect labels.

[afercia]

Any hope this can be fixed for WordPress 5.6? Also looking at the ongoing work on #25428

Moving to the WordPress 5.6. "must have" for visibility.

[retrofox]

Hi, there. I'm running the #25428 pull request.

Just fyi, the aria-label has the following shape:

Choose Saturday, September 26th, 2020. Does that sound good to you?

[afercia]

Will answer on #25428.

[paaljoachim]

I added a comment to the attached PR: #25428 (comment)

[gwwar]

I think #25428 should keep this in mind while it's built, but it might be worth fixing this issue on it's own in another smaller PR.

[retrofox]

I think #25428 should keep this in mind while it's built, but it might be worth fixing this issue on it's own in another smaller PR.

After researching and working on many issues about the date picker, I think the current component should be replaced by the primary component. Otherwise, we are going to create just patches over a component that doesn't seem to be updated lately.

[tellthemachines]

Closing as this has been fixed by #43005, which implements a new DateTimePicker.