Open Bug 1692918 Opened 4 years ago Updated 4 years ago

Devtools a11y inspector rounds values for color contrast but complains about 4.49:1 contrast displayed as 4.5:1

Categories

(DevTools :: Accessibility Tools, defect)

defect

Tracking

(Not tracked)

People

(Reporter: aja, Unassigned)

Details

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

Steps to reproduce:

Run a devtools accessibility contrast check on any page with a select and checked option(s).

Actual results:

Whether combobox or listbox, reports contrast error on the checked option(s).

Expected results:

No contrast error on the checked option(s).

Inspector shows forms.css currently sets

option:checked {
background-color: -moz-html-cellhighlight !important;
color: -moz-html-cellhighlighttext !important;
}

which has contrast very close, but no cigar :)

I've tested on Win10: native/non-native, dark/light, Proton/older.
This is not a new issue; just thought now might be an opportune time to address it.

Emilio, is this improving with / related to the non-native form control work?

Flags: needinfo?(emilio)

Reduced test cases

Combobox:
data:text/html,<select size="1"><option>text</option><option selected>text</option><option>text</option></select>

Listbox:
data:text/html,<select size="3"><option>text</option><option selected>text</option><option>text</option></select>

Not particularly, these are system colors which are not changing with nnt.

In fact, these come directly from windows, so if this is an issue it should probably be reported to Microsoft.

Component: Layout: Form Controls → Widget: Win32
Flags: needinfo?(emilio)

I'm a bit puzzled here: on my Windows machine, the accessibility audit reports the contrast for these cases as 4.50, which seems like it should be good enough to satisfy the guidelines, no?

Is the reported error a result of rounding (e.g. if the computed value is just fractionally shy of 4.5, and displays as 4.50 when rounded but still fails the check), or something like that?

Severity: -- → S4

(In reply to Jonathan Kew (:jfkthame) from comment #5)

I'm a bit puzzled here: on my Windows machine, the accessibility audit reports the contrast for these cases as 4.50, which seems like it should be good enough to satisfy the guidelines, no?

Is the reported error a result of rounding (e.g. if the computed value is just fractionally shy of 4.5, and displays as 4.50 when rounded but still fails the check), or something like that?

Can you clarify what contrast values you were seeing, :aja ? Maybe the devtools a11y contrast reporting needs fixing?

Flags: needinfo?(william.f.goldstein2)

Can you clarify what contrast values you were seeing, :aja ? Maybe the devtools a11y contrast reporting needs fixing?

Seeing devtools a11y reporting value as 4.50, but also as failing.
If I check the colors at Leah Verou's contrast-ratio.com, it shows a 4.49/1 ratio.
So yeah, devtools a11y contrast reporting appears to be rounding displayed value up, but the pass/fail check is likely correct.

I have a feeling Windows made a similar rounding error when picking highlight/highlighttext color pair in the first case.

Flags: needinfo?(william.f.goldstein2)

Morphing this to fix the devtools thing then - given these are OS defaults and they're effectively 4.5:1 (don't think the difference is perceptible...), I think that's the only thing we would fix here...

Component: Widget: Win32 → Accessibility Tools
Product: Core → DevTools
Summary: fix color contrast on select's option:checked → Devtools a11y inspector rounds values for color contrast but complains about 4.49:1 contrast displayed as 4.5:1
You need to log in before you can comment on or make changes to this bug.