1661638 - Mousing over or clicking Print Preview's "Color mode", "Destination" and "Margins" label text highlights their dropdown list

Status: RESOLVED WONTFIX

(Toolkit :: Printing, defect, P2)

Description

[Chris Peterson [:cpeterson]]

Steps to reproduce

1. Open Print Preview for a web page
2. Mouse over Print Preview's "Color mode" label above the Color mode dropdown list.
3. Click the "Color mode" label text.

Expected result

Nothing should happen. The Color mode dropdown list should not be highlighted. Clicking the "Color mode" label text should not set focus to the dropdown list.

Actual result

The Color mode dropdown list is highlighted. Clicking the "Color mode" label text sets focus to the dropdown list, which is misleading because the list can't be opened unless you click on the dropdown list itself.

This doesn't happen mousing over the "Pages" label above the Pages dropdown list.

Comment 1

[Itiel]

(In reply to Chris Peterson [:cpeterson] from comment #0)

This doesn't happen mousing over the "Pages" label above the Pages dropdown list.

Note that the "Pages" label is the only one being unaffected. The same issue is reproducible also on "Destination" and "Margins" labels.

Comment 2

[Blake Winton (:bwinton) (:☕️)]

Accessibility-wise, I'm not sure I agree, so I'm tagging Jamie and Mark for a second opinion. :)
But we should probably make the Pages label behave the same as the other ones, one way or the other…
(Looking in the code, it seems like the pages label is for a div containing the select element, whereas the other ones are for the select element directly…)

Comment 3

[Marco Zehe (:MarcoZ)]

A label pointing to a div sounds like a bug to me. Does the div have a role attribute? If not, it's a bug, and the label should point to the select, too. Labels pointing to actual selects or input elements is important for accessibility, both screen readers as well as mouse/touch targets.

Comment 4

[Blake Winton (:bwinton) (:☕️)]

No role that I can see…
I wonder if it's pointing to a div because we don't have the select element when the page is created?

The HTML is at https://searchfox.org/mozilla-central/source/toolkit/components/printing/content/print.html#92-103
The Custom Element code for it is at https://searchfox.org/mozilla-central/source/toolkit/components/printing/content/print.js#972-1092

Comment 5

[Marco Zehe (:MarcoZ)]

Shouldn't matter, as soon as the select is inserted, there will be events that make the label work properly I think.

Comment 6

[James Teh [:Jamie]]

The Pages select does have an aria-label, so it is screen reader accessible.

As to whether the label should be associated with the select, this is not as straightforward as it might seem. Generally, clicking or touching a label should focus the associated field, as this gives it a bigger mouse/touch target. (The fact that it doesn't open the select is arguably a bug, though, since clicking the select does open it.) In this case, though, the div with which the label is associated is actually a group of controls (more like a fieldset). If you select custom in the page range select, it adds additional fields to that div to set the start and end pages. So, yes, this is inconsistent, but it's also a different scenario, so I think the inconsistency is reasonable.

Comment 7

[Blake Winton (:bwinton) (:☕️)]

Cool, I'll resolve this as WONTFIX then, but only because we don't have a "By Design" resolution… 😄
Thanks for filing the bug, Chris!