[a11y]: Date picker examples and Figma assets rely on a placeholder or inconsistent date masks

[mbgower]

Package

@carbon/react

Browser

Chrome

Operating System

MacOS

Package version

https://carbondesignsystem.com/components/date-picker/usage

React version

https://carbondesignsystem.com/components/date-picker/usage

Automated testing tool and ruleset

n/a

Assistive technology

No response

Description

Carbon has some clearly stated requirement in the Usage material for Date picker, as follows:

Despite this, Carbon's illustrations for date picker seem to default to using only the placeholder text for date mask info. Date masks as placeholders -- or other variants -- appear through the Usage and Style info in Carbon's documentation:

^ In the Live demo

^ In examples

^ On the style page

^ In the Date input specs

^ In the size specs

^in the React storybook

In Figma, every example shows it without it part of the label or helper text

---

Where Carbon does show a mask, it tends to be inconsistent:

In a different position, in the States material

^ In a different position (and format) on the Light variant example ---

Note that in the quoted text at the top, Carbon also says:

When using calendar picker the date format will be automated if the user selects from the calendar menu.

This implies it is okay to have the mask in the placeholder here, but it's not really valid. First, at the moment the ONLY way for a keyboard user to easily changed date and month is to manually enter a date; so the date mask remains a problem) even where the calendar is offered.
Second, there are two very widespread and contradictory ways of showing month/day combinations (MM/DD/YYYY and DD/MM/YYYY).

Is 7/8/2022 the seventh of August or the eighth of July? Without the mask, users cannot tell, so half your audience is going to be wrong in their assumption.

Outside the confusion for anyone trying to interpret a date once the placeholder date mask info has been replaced by an actual date, the placeholder causes several challenges specific to accessibility:

1. The placeholder text has very low contrast, and may be difficult to read by anyone with low vision
2. The placeholder text is not surfaced consistently by screen readers and other ATs.

Carbon needs to have a consistent default presentation of date mask which is adopted across its prototyping tools, coding repos and documentation.

---

Note, this and #11800 have been separated from less critical date picker considerations/issues because they directly affect the accessibility guidance that can be crafted. As such, they constitute higher priority considerations.

WCAG 2.1 Violation

No response

Reproduction/example

https://carbondesignsystem.com/components/date-picker/usage

Steps to reproduce

Go to the Figma library, react repo or Carbon documentation site and look.

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[jnm2377]

I think what we can do to address this is:

1. update our storybook example to have helperText for simple datepickers
2. make the helperText prop default value be the date format for type="simple" date pickers

[mbgower]

@jnm2377 those two technical changes will definitely help.
As discussed, there are also design considerations here, which I'm hoping @laurenmrice and @aagonzales can lead, to do with both the visual examples in Carbon documentation, and the prototyping assets in Figma and Sketch.

[mbgower]

My recommendation would be to have the default version of all date pickers have the date mask present in the Helper text by default. This will arguably improve the experience for many users.

As discussed in the Date picker usage.pdf, I'm not certain how/if the OS-level date preferences affect anything in Carbon (i.e., if I have my system set to dd/mm/yyyy, does the browser inherit this and alter Carbon's default of mm/dd/yyyy?). The technical details should be considered as part of this decision.

[mbgower]

@sstrubberg I see you folks have put it in the Design System backlog. I agree this is pretty much a design issue. Hopefully @laurenmrice and team will review this.

[aagonzales]

Design task:

• Turn on helper text for all default date inputs