2055426 - Insufficient color contrast of weekday headers and out-of-month days in native <input type="date"> calendar picker (WCAG 2.2 SC 1.4.3 failure)

Status: NEW

(Core :: Layout: Form Controls, defect, P2)

Description

[Radoslav Ďurač]

Attachment: Calendar picker in two states: all days out of min/max range (March 2019, inactive gray) and a regular in-range month (February 2018) showing low contrast weekday headers, weekend labels and out-of-month days

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0

Steps to reproduce:

1. Open a page containing the following markup:

<label for="start">Start date:</label>
<input
type="date"
id="start"
name="trip-start"
value="2018-07-22"
min="2018-01-01"
max="2018-12-31" />

2. Click the input (or press Space/Enter with keyboard focus) to open the native calendar picker.
3. Measure the color contrast of the weekday header labels and the day numbers using a contrast analyzer (e.g. TPGi Colour Contrast Analyser).

Actual results:

Several text elements in the calendar picker do not meet the WCAG 2.2 SC 1.4.3 minimum contrast ratio of 4.5:1 (default light theme, Windows, no OS contrast settings):

1. Weekday header labels (Mon-Fri): #808080 on #FFFFFF = 3.9:1
2. Weekend header labels (Sat, Sun): light red approx. #F68080 on #FFFFFF = 2.5:1
3. Out-of-month day numbers (previous/next month, still clickable and selectable): #808080 on #FFFFFF = 3.9:1
4. Out-of-month weekend day numbers: approx. #F68080 on #FFFFFF = 2.5:1

Additionally, in-month weekend days use #EE0000 on #FFFFFF = 4.53:1, which passes only marginally, and the weekend distinction is conveyed by color alone (related to SC 1.4.1 Use of Color).

Day numbers outside the min/max range are inactive, so SC 1.4.3 does not formally apply to them, but their contrast is also very low (below 2:1), which affects readability for low vision users.

Note: the color values above were measured from screenshots, so the actual values in the source code may differ slightly. However, the contrast ratios are far enough below the required thresholds that minor measurement deviations do not change the outcome.

Screenshots with the affected states attached.

Expected results:

All text in the picker that is part of active UI (weekday headers, in-month and out-of-month day numbers) should have a contrast ratio of at least 4.5:1 against the background, per WCAG 2.2 SC 1.4.3 (Contrast Minimum).

Suggested fix: darken the gray to at least #767676 and the weekend red to at least #D30000 (or preferably darker) to provide a safe margin.

Beyond fixing the specific values above, the entire calendar picker should be comprehensively reviewed from an accessibility perspective: all its visual states and appearances (default, hover, focus, selected, disabled/out-of-range, light and dark theme, OS high contrast modes) should be tested against WCAG 2.2 SC 1.4.3 and 1.4.11, and all insufficient contrasts should be fixed, not only the ones reported here.

Standards context:

• WCAG 2.2 SC 1.4.3: web authors cannot remediate this, as the picker is user agent UI that is not author-styleable, so pages using <input type="date"> cannot achieve full WCAG conformance in Firefox. This is legally relevant for public sector websites in the EU, which are required to conform to WCAG via EN 301 549 clause 9 under Directive (EU) 2016/2102.
• EN 301 549 clause 11.1.4.3 (Contrast Minimum for non-web software) applies to Firefox itself as software.
• UAAG 2.0, Guideline 5.1 (Follow specifications) recommends that user agent UI complies with WCAG (informative W3C Note).

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug is an accessibility bug, but please revert this change in case of error.

Comment 3

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:alaskanemily, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[James Teh [:Jamie]]

S2 for insufficient contrast per our accessibility triage guidelines. Some users would not be able to use the date picker as a result.

Comment 5

[BugBot [:suhaib / :marco]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:emilio, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Sure. This is due to these opacity rules.

Do you know what the right thing to use here would be? I guess --text-color-disabled at least for the disabled entries.

Using opacity for the header seems dubious but we could probably bump it to .8 or so...

Comment 7

[Sam Johnson]

I started working on a patch to convert this to use design system tokens a while ago but never finished; is there an appetite for that approach?