Post date block - date format options are not clear for screen reader users and items are not announced as checked

[talldan]

Description

The Post Date block has a 'Format Settings' dropdown in its block inspector.

When using Voiceover to read out these options, the output can be confusing. An example is that both the 'Feb 25, 2022' and 'Februrary 25, 2022' options in the dropdown are announced in exactly the same way as 'February 25th 2022', so there's no way to tell them apart. I'm not sure what the situation is like in other screen readers, but it sounds as though Voiceover does some normalization of any dates it reads.

There also doesn't seem to be a way to tell which item is checked. All items are announced as 'selected'.

Step-by-step reproduction instructions

(with Voiceover active)

1. Add a post date block (it should be ok to do this in the post editor.)
2. Tab to the block inspector an keep tabbing until you get to the 'Date format, list block pop up'
3. Press enter to open the dropdown
4. Use arrow keys to cycle through the list and listen to the options

Screenshots, screen recording, code snippet

No response

Environment info

Safari / Voiceover using latest Gutenberg trunk

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[joedolson]

Confirmed that this is still an issue, and also impacts other screen readers: tested with NVDA/Firefox.

Testing with NVDA, I used the visual display of what NVDA was reading and confirmed that this is actually a pronunciation issue: what NVDA prints to the screen is "Jan", but what it actually says is "January".

This is probably not something we can fix; these decisions are ultimately up to the voice synthesizer - so it may vary depending on which voice synthesizer a user is working with. Because the voice synthesizer process the language only after the screen reader has interpreted the information passed from the accessibility API, nothing we send to the API (e.g. via ARIA) will have any impact on this.

Abbreviation expansions are done by voice synthesizers to increase comprehension, since in most cases 'SD' is less meaningful than 'South Dakota'. However, this is certainly a case where the end result can be a problem.

I suggest we close this, but if @alexstine has any thoughts, feel free.

[alexstine]

There is nothing we can do about it. The best solution here would be to convert this to a radio button input that way users can use browse mode to explore the text itself, this would be complicated in a select field.

[afercia]

There also doesn't seem to be a way to tell which item is checked. All items are announced as 'selected'.

This is a serious bug, not sure whether it comes from the Gutenberg implementation or from the downshift package.

The point is that the usage of the aria-selected attribute is different depending on which ARIA pattern is used with. I've seen other libraries getting a confused on this point.

• Listbox (which is this case): aria-selected must be set to true on the option that is actually the currently selected value. If no value is selected aria-selected must be false or omitted. Instead, in this implementation is is set on the item that is currently highlighted while navigating the options.
• Combobox (input field + Listbox of suggestions): aria-selected must be set to true on the item that is currently highlighted while navigating the options.

As such, thee date format dropdown is not compliant and totally unusable by screen reader users.

If its not possible to fix this because the bucs is upstream in downshift, I suggest to use a native select element instead and remove all usages of downshift from the codebase.