input-date-picker does not announce the purpose of each input when in range mode

[sansth1010]

Check existing issues

• I have checked for existing issues to avoid duplicates

Summary

US Department of Veterans Affairs has reported accessibility bug on their Hub site's search page which uses input-date-picker component to select date range. input-date-picker doesn't announce what each field in the component is for.

Actual Behavior

As seen in the video below, when input field of input-date-picker gets in focus - voice over says "You are currently in a menu pop-up combo box". Please unmute the video to hear the voice over. You can also see texts of what voice over is saying on the bottom left screen.

Screen.Recording.2023-10-12.at.12.25.01.PM.mov

Expected Behavior

We should hear labels associated with the inputs inside of input-date-picker range like "Start date" and "End date".

Reproduction Sample

https://codepen.io/sansth1010/pen/rNobOwe

Reproduction Steps

1. Open VoiceOver (CMD+F5)
2. Click on "Date range" to expand accordion.
3. Press Ctrl+Option+right-arrow to move focus to first date range input

Reproduction Version

1.4.1

Working W3C Example/Tutorial

No response

Relevant Info

No response

Regression?

No response

Priority impact

p2 - want for current milestone

Calcite package

• @esri/calcite-components
• @esri/calcite-components-react
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Hub

[geospatialem]

Related: #8480

[driskull]

@geospatialem part of the issue might be that the assistive text element is set to aria-hidden="true"

calcite-design-system/packages/calcite-components/src/components/input-date-picker/input-date-picker.tsx

Lines 591 to 593 in 9bfbb42

	<span aria-hidden="true" class={CSS.assistiveText} id={this.placeholderTextId}>
	Date Format: {this.localeData?.placeholder}
	</span>

I'm wondering if this should just use the label property of the calcite-input-text instead of aria-describedby? Seems like a label is more appropriate here? (which would translate to aria-label within the input-text)

Also the Date Format: text isn't localized. I think we need a string Date Format: {format}

@macandcheese @anveshmekala looks like table-cell, table-header, and text-area are doing the same thing. I don't think these elements made for screen readers should have aria-hidden on them.

calcite-design-system/packages/calcite-components/src/components/table-cell/table-cell.tsx

Lines 247 to 250 in 9bfbb42

	<span
	aria-hidden={true}
	aria-live={this.focused ? "polite" : "off"}
	class={CSS.assistiveText}

calcite-design-system/packages/calcite-components/src/components/table-header/table-header.tsx

Lines 264 to 267 in 9bfbb42

	<span
	aria-hidden={true}
	aria-live={this.focused ? "polite" : "off"}
	class={CSS.assistiveText}

calcite-design-system/packages/calcite-components/src/components/text-area/text-area.tsx

Lines 369 to 371 in 9bfbb42

	<span aria-hidden={true} aria-live="polite" class={CSS.assistiveText} id={this.guid}>
	{this.replacePlaceHoldersInMessages()}
	</span>

[driskull]

the aria-hidden on those elements isn't using toAriaBoolean so they really aren't doing anything anyway.

They would be rendered as aria-hidden and not aria-hidden="true". I think that is meaningless

[macandcheese]

Yeah happy to update that as needed - For the table-cell it was an attempt at a Safari specific workaround

calcite-design-system/packages/calcite-components/src/components/table/table.tsx

Line 170 in 9bfbb42

@State() readCellContentsToAT: boolean;

we can remove that altogether for the next major browser version, I think.

[driskull]

I wonder if input-date-picker should have its own label property for users to set a custom label?

Currently, they are stuck with Date Format. If they have multiple date pickers this wouldn't be very useful.

[geospatialem]

I wonder if input-date-picker should have its own label property for users to set a custom label?

Currently, they are stuck with Date Format. If they have multiple date pickers this wouldn't be very useful.

@driskull I like this approach. This also came up in a Living Atlas audit in December 2024. Having a label attribute with more context would be beneficial.

Currently in NVDA the following is read back when the component does not have a value, which could be improved upon:

MM/DD/YYYY edit blank