[pickers][DatePicker v6.14.0] accessibility

[matchmakers69]

Steps to reproduce

https://codesandbox.io/p/sandbox/create-react-app-typescript-forked-2c4vqj?file=%2Fsrc%2Findex.tsx%3A23%2C69

Current behavior

My current implementation of MUI DatePicker looks like:

import { BaseTextFieldProps } from "@mui/material";
import { AdapterLuxon } from "@mui/x-date-pickers/AdapterLuxon";
import { DatePicker as MUIDatePicker } from "@mui/x-date-pickers/DatePicker";
import { LocalizationProvider } from "@mui/x-date-pickers/LocalizationProvider";
import { ReactComponent as CalendarIco } from "assets/icons/calendar-icon.svg";
import useValidationErrorMessage from "hooks/useValidationErrorMessage";
import { DateTime } from "luxon";
import { useController, useFormContext } from "react-hook-form";
import { palette } from "theme/palette";

type Views = "day" | "month" | "year";

type DatePickerProps = BaseTextFieldProps & {
  name: string;
  fullWidth?: boolean;
  inputFormat: string;
  hasPlaceholder?: boolean;
  value?: string | null;
  disablePast?: boolean;
  disableFuture?: boolean;
  label?: string;
  ariaRequired?: boolean;
  ["data-testid"]?: string;
  openTo?: Views;
};

const CalendarIcon = () => {
  return <CalendarIco data-testid="calendar-icon" />;
};

const DatePicker = ({
  name,
  inputFormat,
  fullWidth: propFullWidth,
  variant = "standard",
  className = "data-picker-date-field",
  hasPlaceholder = false,
  value = null,
  disablePast = false,
  disableFuture = false,
  ariaRequired,
  label = "",
  "data-testid": dataTestId = "date-picker",
  openTo = "day",
}: DatePickerProps) => {
  const {
    formState: { errors },
    clearErrors,
    control,
  } = useFormContext();

  const { field } = useController({ control, name, defaultValue: null });
  const errorMessage = useValidationErrorMessage(errors[name]?.message);

  return (
    <LocalizationProvider dateAdapter={AdapterLuxon}>
      <MUIDatePicker
        views={["day", "month", "year"]}
        openTo={openTo}
        data-testid={dataTestId}
        className={className}
        format={inputFormat}
        value={value !== null ? DateTime.fromFormat(value, "dd/MM/yyyy") : null}
        label={label}
        defaultValue={null}
        inputRef={field.ref}
        onChange={(date) => {
          clearErrors();
          field.onChange(date?.toFormat(inputFormat));
        }}
        slots={{
          openPickerIcon: CalendarIcon,
        }}
        slotProps={{
          popper: {
            className: "data-hj-suppress",
          },
          textField: {
            variant: variant,
            helperText: errorMessage,
            error: !!errors[name],
            fullWidth: propFullWidth,
            InputProps: {
              placeholder: hasPlaceholder ? inputFormat.toUpperCase() : "",
              "aria-required": ariaRequired,
            },
            sx: {
              "& input": {
                padding: "17px 0 9px 0",
              },
              "& .MuiInputBase-inputAdornedEnd": {
                padding: "17px 28px 9px 0",
              },
              "& fieldset": {
                borderColor: palette.border.light,
                color: palette.text.default,
              },
              "& svg": {
                display: "inline-block",
                width: 22,
                height: 22,
              },
            },
          },
          inputAdornment: {
            position: "end",
          },
        }}
        disablePast={disablePast}
        disableFuture={disableFuture}
      />
    </LocalizationProvider>
  );
};

export default DatePicker;

Expected behavior

Desktop screenreader

• WHEN I use a desktop screenreader (NVDA, JAWS, VoiceOver) AND
• I use the tab key to move focus to the date dialog button
  • I HEAR The purpose of each control is clear
  • I HEAR Buttons identify as buttons, dialog identifies itself dialog or modal, date grid table may identify itself as table or grid
  • I HEAR The launch button indicates it has a popup, menu or dialog; days are announced with month and year
  • I HEAR Date options express state (pressed, selected, disabled/dimmed)
• THEN when I use the spacebar and/or enter key I HEAR the date picker dialog appears
• THEN when I use the arrow keys I HEAR the selection moves through next/previous dates
• THEN when I use the home/end key I HEAR the selection moves to the first/last day of the current week
• THEN when I use the page up/down key I HEAR the grid of dates moves to the next/previous month
• THEN when I use shift key + page up/down I HEAR the grid of dates moves to the next/previous year
• THEN when I use the spacebar and/or enter key I HEAR the button or selection is activated
• THEN when I use the escape key I HEAR the date picker dialog disappears and focus returns to the date dialog button

Mobile screenreader

• WHEN I use a mobile screenreader (Talkback, VoiceOver) AND
• I swipe to focus on the date dialog button
  • I HEAR The purpose of each control is clear
  • I HEAR Buttons identify as buttons, dialog identifies itself dialog or modal, date grid table may identify itself as table or grid
  • I HEAR The launch button indicates it has a popup, menu or dialog; days are announced with month and year
  • I HEAR Date options express state (pressed, selected, disabled/dimmed)
• THEN when I doubletap with the button in focus I HEAR the date picker dialog appears
• THEN when I swipe through the dialog I HEAR the date options and controls come into focus
• THEN when I doubletap with the selection or button in focus I HEAR the intended action occurs

Context

Basically I need to make my current implementation a bit more accessibility friendly

Your environment

npx @mui/envinfo

``` Don't forget to mention which browser you used. Output from `npx @mui/envinfo` goes here. ```

Search keywords: accessibity screen readers, MUI DatePicker

[LukasTy]

Hello @matchmakers69, thank you for creating this issue. 👍 Could you clarify the issue by providing the points that you think are missing from your list? If I understood correctly, you have already gone through your process of testing and noticed certain behaviors missing, so, it would be great having a better direction so that we could focus on what is missing.

One clear behavior that we are missing is the Shift+PageUp/PageDown to move through the years.

[matchmakers69]

Great! , thanks for reply @LukasTy

These things dont work as they should:

1. I want to understand what new date has been selected via a screenreader
2. I want to understand what date exists in the field before I have amended it
3. I want to be able understand navigation through months and years to find the desired date using a screenreader
4. I want to be able to select my desired date using a keyboard
5. I want to be notified if I have selected an invalid date via a screenreader

Just wondering if there would be a way or what i need to do to achieve that with my current implementation?

[LukasTy]

I'll start by saying that our behavior has been inspired by this example: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/datepicker-dialog/.

These things dont work as they should:

1. I want to understand what new date has been selected via a screenreader

Do you mean the dialog behavior here? I think that our behavior is nearly identical to WAI-ARIA example. Do you have ideas on how we could improve it? What would you expect to hear when changing days?

2. I want to understand what date exists in the field before I have amended it

By "field" do you mean the input? If yes, then I suggest you read about the accessible DOM structure. What you are asking is practically impossible by using an input and going for the behavior we have now.

3. I want to be able understand navigation through months and years to find the desired date using a screenreader

Do you refer to the dialog experience here? What do you feel missing in the months and years navigation? Is it the missing keyboard interaction I've referred to? Currently, the active month and year are announced when the month or year changes.

4. I want to be able to select my desired date using a keyboard

Do you mean the input/field behavior here again? If yes, please refer to the answer to 2nd question.

5. I want to be notified if I have selected an invalid date via a screenreader

Do you mean the field/input behavior here as well? In this case, NVDA does mention when the input is invalid for accessible DOM structure.

Just wondering if there would be a way or what i need to do to achieve that with my current implementation?

I'm unsure if that is doable with changes only in userland. The internal components will need certain changes.

[github-actions[bot]]

The issue has been inactive for 7 days and has been automatically closed.

[github-actions[bot]]

The issue has been inactive for 7 days and has been automatically closed.