[DatePicker] Accessibility issue regarding heading

Environment

Tech	Version
@material-ui/pickers	3.2.10
material-ui	4.95
TypeScript	n/a
React	16.8.6
Browser	All
Peer library	moment 2.4.0

Steps to reproduce

For the following steps I am referring to: Keyboard input masked time picker

1. Go to the demo for timepicker, section for Keyboard input linked above and open up the modal using the calendar icon button, opening up to large numbers showing 4:45AM/PM.
2. Chrome inspect the DOM Elements associated with the Toolbar Button / Toolbar Text Components (Example: 4, 45, AM, or PM text elements).
3. Observe the associated element for the time (4 or 45). It produces an element of h2 with a className of MuiTypography-root MuiPickersToolbarText-toolbarTxt MuiPickersToolbarText-toolbarBtnSelected MuiTypography-h2

Expected behavior

The DOM elements for the Toolbar Text / Toolbar button should not be part of the heading structure.

Actual behavior

The toolbar text button uses an h2 variant, as a result the component is then changed to be an h2. I have noticed it with all elements throughout all the pickers, anytime a variant of h1…h6 is provided.

Live example

Keyboard input masked time picker While this is the demo site, the behavior persists on my codebase and causes a disruption to my heading structure.

Additional Notes

This issue seems to be widespread, but has a base issue within toolbar text. So I think solving it in that component, would reflect changes in all the components.

An additional way to test is by inspecting with Chrome and running document.querySelectorAll(“h1, h2, h3, h4, h5, h6”) in the console. I did this as a quick test and noted that the headings jump around quite a bit and do not follow an expected order.

I am open to contributing if it helps. Within the component here: material-ui-pickers/lib/src/_shared/ToolbarText.tsx, pass over a component of span for Typography to render.

[gracektay]

@eps1lon Based on my experience, less headings is better than broken😊. Much like ARIA, unless you can do it perfectly it can do more harm than good unless you REALLY know what you’re doing. Anyways, thanks we’re looking forward to v5 on our team (or at least I am)!!! I’d also be happy to help with triage, it looks like stack overflow would be a good place to look too maybe?

[eps1lon]

I think generally we shouldn’t use any heading elements in components. It’s too easy to break the heading structure this way.

This begs the question what’s worse: a broken heading structure or no/too little heading structure. But this is a more general question that doesn’t need to be answered here. All the advise I saw was “don’t break the heading structure” so we stick to it until we learn otherwise.

I’ll check out the issues every now and then and see how I may help, but feel free to tag me if there is something more pressing in your roadmap!

It’s a continuous effort. Our biggest problem is triaging issues and making them reproduceable. Most of the time it’s some validator that complains which is an issue but it’s more important how actual assistive technology (e.g. screen readers) behave.