[pickers] The Datepicker placeholder is not announced properly

[satya-imaginea]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Steps to reproduce 🕹

Link to live example:

https://user-images.githubusercontent.com/76739349/236778762-824aa3b0-7500-4d6a-a1d8-081f359053b3.mov

Steps:

1. Open mui datepicker website
2. Turn on the screen reader (voice over)
3. focus on the date picker input and observe the placeholder announcement, which says 'mm/dd/yy' for 'mm/dd/yyyy'. It may confuse the users with visual issues.

Current behavior 😯

focus on the date picker input and observe the placeholder announcement, which says 'mm/dd/yy' for 'mm/dd/yyyy'. It may confuse the users with visual issues.

Expected behavior 🤔

the placeholder should announce properly letter by letter instead of announcing 'yyyy' as single word. We may need to set aria-label('Y Y Y Y ') to fix this. Without affecting the visible placeholder, would you use aria-lable/aria-placeholder as "M M / D D / Y Y Y Y" internally?

Context 🔦

We are trying to support accessibility for the date picker.

Your environment 🌎

npx @mui/envinfo

``` System: OS: macOS 13.3.1 Binaries: Node: 14.20.0 - ~/.nvm/versions/node/v14.20.0/bin/node Yarn: 1.22.19 - ~/.nvm/versions/node/v14.20.0/bin/yarn npm: 6.14.17 - ~/.nvm/versions/node/v14.20.0/bin/npm Browsers: Chrome: 112.0.5615.137 Edge: Not Found Firefox: 108.0.2 Safari: 16.4 npmPackages: @emotion/react: ^11.10.6 => 11.10.6 @emotion/styled: ^11.10.6 => 11.10.6 @mui/base: 5.0.0-alpha.123 @mui/core-downloads-tracker: 5.11.15 @mui/material: ^5.11.14 => 5.11.15 @mui/private-theming: 5.11.13 @mui/styled-engine: 5.11.11 @mui/system: 5.11.15 @mui/types: 7.2.3 @mui/utils: 5.11.13 @mui/x-date-pickers: ^6.0.3 => 6.0.3 @types/react: ^18.0.0 => 18.0.31 react: ^18.2.0 => 18.2.0 react-dom: ^18.2.0 => 18.2.0 styled-components: ^5.3.9 => 5.3.9 typescript: ^4.4.2 => 4.9.5 ```

[alexfauquette]

would you use aria-lable/aria-placeholder as "M M / D D / Y Y Y Y" internally?

I don't think it's a good idea. The aria documentation use dates in their examples of aria-placeholder and they do not add space: https://www.digitala11y.com/aria-placeholderproperties/

[satya-imaginea]

May we consider announcing 'yyyy' as single word(/yy/) as expected behaviour? I thought, making voiceover/talkback announce it letter by letter(/y y y y/) is more user-friendly, would you please suggest if there is any workaround? (I tried overriding aria-placeholder but it is not working)

@alexfauquette

[alexfauquette]

Here is an example. You can also override the placeholder the same way.

https://codesandbox.io/s/romantic-villani-1lud2f?file=/demo.tsx

But once again, hacking the HTML to fix a bug in the voice reader is not a safe road

[satya-imaginea]

@alexfauquette Thank you for your codesandbox example. I agree with you on not announcing something different than what we show on screen. but here, we are trying to announce the same visible placeholder letter by letter instead of treating it as a single word(yyyy).

when I tested the example, the aria-placeholder is not considered.

On mac:

https://github.com/mui/mui-x/assets/76739349/f2147247-e303-4a0d-bbf5-da05e2ffeb86

On android:

https://github.com/mui/mui-x/assets/76739349/ecc0560d-7eab-409b-9824-83911c1b47a9

Thank you @alexfauquette for your help.

[alexfauquette]

Ok, I got it. The screen reader will not care about the placholder or aria-placeholder because the input has a value.

The MM/DD/YYYY is the value of the input when focused. The reason of this hack being we need to set a value to be able to have the section selection.

I don't think you can override the voiceover description without modifying the visible text

@LukasTy Did you encountered similar stuff when investigating a11y?

[LukasTy]

Did you encountered similar stuff when investigating a11y?

When I was investigating a11y support for the fields, the current placeholder/value switching behavior was not yet present. The experimentation is available in a draft PR. TL.DR.: If there is a need to provide a custom label for accessible devices, simply specifying a static or dynamic aria-label should help.

In regards to the solution from the MUI side, we plan to come up with a more a11y friendly solution for field components in v7.

[vishal-kadmos]

The MM/DD/YYYY is the value of the input when focused. The reason of this hack being we need to set a value to be able to have the section selection.

Would it be possible to override/disable this behaviour?

[LukasTy]

Would it be possible to override/disable this behaviour?

1. What is the reason you want to disable it?
2. What would the end result look like? Have no placeholder, but always assign the format placeholder to value? Mind you, that the reason we did not do it is to avoid having empty fields look like filled in (field with a value has black color, whereas placeholder uses light grey).

[clementineb3003]

Would it be possible to override/disable this behaviour?

1. What is the reason you want to disable it?
2. What would the end result look like? Have no placeholder, but always assign the format placeholder to value? Mind you, that the reason we did not do it is to avoid having empty fields look like filled in (field with a value has black color, whereas placeholder uses light grey).

I also wish I could override the input value. To answer your questions, the "DD/MM/YYYY - DD/MM/YYYY" is quite massive looking and I would prefer something a little more subtle like "Pick a date range...", same text as my placeholder. My ideal default value would be an empty string so I could just visualize my placeholder when the input is focus ("Pick a date range..." in light grey).

[LukasTy]

My ideal default value would be an empty string so I could just visualize my placeholder when the input is focus ("Pick a date range..." in light grey).

You can override the placeholder to anything you want. Not having a value is not an option at the moment. Value attribute was always controlled by the library, in v5 it was the mask approach, while in v6 we went with the more superior fields approach having much more functionality as compared to the mask. If I understand your idea/request correctly, it would mean that you want just dummy input elements and leave the selection of the date to the user using the picker dialog/modal experience. This would mean, that the field/input experience would be non-existent, and in such case, the picker should probably not even allow changing value in any other way than the picker dialog/modal..?

I'm honestly not sure that we should be providing such an option out of the box. It could have quite a few a11y challenges. Don't forget that you can build your own custom behavior using the exposed subcomponents, like the StaticDateRangePicker or even a lower level DateRangeCalendar.

[japdeloitte]

How would you change DD/MM/YYYY to be in a different language that you specify? like DD/MM/AAAA for spanish? seems like when I add placeholder it doesnt work: slotProps={{ ...slotProps, textField: { inputProps: { placeholder: "MM/DD/AAAA", }, }, }}

[LukasTy]

@japdeloitte The "placeholder" format is based on localization. If you want a Spanish format, feel free to provide the Spanish locale. 😉

[japdeloitte]

Still didnt work. It did change the calendar language. but not the MM/DD/YYYY to DD/MM/AAAA as I had hoped. It did change the order though switching the DD with MM. :

[LukasTy]

@japdeloitte Could you share a live reproduction example or a minimal GH repo with your setup? Or maybe a video recording? 🤔 It does seem to work in this demo. 🤷

[japdeloitte]

Hmm spanish did work for me. When I forked your demo and changed locale to korean, it has all kinds of issues. like it shows DD/MM/YYYY and its showing abril for month: https://stackblitz.com/edit/react-bwgeeu-hwvppj?file=Demo.tsx

[japdeloitte]

Looks like missing translations for korean, vietnamese, and chinese. Probably more but these are ones I tested.

[LukasTy]

@japdeloitte You forgot to update the moment/locale/ import in your demo. The localeText is responsible for translations that we have a control over, whereas the locale from the respective adapter handles the proper format (separator), date (formatting) localization, etc.

[japdeloitte]

No, I did update it. I went into the code you have for translations and it is incorrect for the languages I listed above. korean has YYYY. for now I have used custom locale const customLocaleText: Partial<PickersLocaleText> = { fieldYearPlaceholder: () => 'my year translation', fieldMonthPlaceholder: () => 'my month translation', fieldDayPlaceholder: () => 'my day translation',

[japdeloitte]

https://github.com/mui/mui-x/blob/559ae0984dfe3fe96c646a62fc48130349009349/packages/x-date-pickers/src/locales/koKR.ts