bug(material/datepicker): WAVE tool reports the accessibility error (WCAG A) as "Empty table header" to datepicker calendar popup views (month, year, multi-year).

[jumbo6]

Is this a regression?

• [ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

WAVE tool reports the accessibility error (WCAG A) as "Empty table header" to datepicker calendar popup views (month, year, multi-year).

An empty

for the divider causes the error.

Reproduction

Steps to reproduce:

To replicate the issue,

1. go to Datepicker examples page: https://material.angular.io/components/datepicker/overview

2. click a calendar icon to popup the calendar view. Then open WAVE extension.

Expected Behavior

in

, use a hidden text to describe the divider.

Actual Behavior

To replicate the issue, go to Datepicker examples page, click a calendar icon to popup the calendar view. Then open WAVE extension.

https://material.angular.io/components/datepicker/overview

Environment

• Angular:
• CDK/Material:
• Browser(s):
• Operating System (e.g. Windows, macOS, Ubuntu):

[zarend]

Hello @jumbo6 ,

Thank you for bringing this to our attention. I can see how a table header could be inappropriate if a table is only used for layout. It could be inappropriate to communicate to screen readers that there's a header if the th is not intended to actually communicate a header.

Sometimes AXE, WAVE and other a11y checkers or linters give false positives.

In the Datepicker month-view, the calendar is an ARIA grid role and the header element is aria-hidden. By looking at the Chrome a11y tree, we can see that the header is not included in the a11y tree, which means that assistive technology does not see it.

It may be that the WAVE checker always reports when there is an empty th element, even if it does not actually communicate semantics to screen readers.

I do not think that this check is causing an actual accessibility problem for users, and I believe it is safe to ignore it.

Have you been seeing reports from users of your applications that this is causing a problem?

Best Regards,

Zach

[jumbo6]

RE: I do not think that this check is causing an actual accessibility problem for users, and I believe it is safe to ignore it.

Thank you for your response. I haven't heard anything from the end users. This is the report from the testers.

Other than the empty header, there are 2 empty labels in mat-calendar-body.html...

<label [id]="_startDateLabelId" class="mat-calendar-body-hidden-label"> {{startDateAccessibleName}} <label [id]="_endDateLabelId" class="mat-calendar-body-hidden-label"> {{endDateAccessibleName}}

can you add a condition like ngif="startDateAccessibleName", so the label is removed when there is no use of it?

[zarend]

Hello folks,

Thanks for getting back to us. Angular components doesn't have a requirement to cleanly pass automated accessibility checks.

This isn't something I'm able to take on right now, but we have this issue report to track this.

Best Regards,

Zach

[zarend]

#27241