1008583 - [New Tab page] Invisible buttons with browser.display.use_document_colors=false

Status: RESOLVED WONTFIX

(Firefox :: New Tab Page, defect, P3)

Description

[Florens Verschelde :fvsch]

Attachment: New tab page with and without document colors (missing buttons)

When selecting the “Use my own colors” option in Preferences > Content > Colors… (browser.display.use_document_colors=false), several buttons in the new tab page are invisible:

- #newtab-toggle
- .newtab-control-pin
- .newtab-control-block

The issue is that those buttons are displayed using background images (with an image sprite), rather than <img> elements. This is a common accessibility issue with CSS image sprites.

A similar issue was raised for the preview images in Bug 737877.
One solution proposed in that bug was to load the new tab page as a type="chrome" document, so that browser.display.use_document_colors doesn’t apply.
I’ll note that the about:addons page is affected as well (I haven’t checked the accessibility there).

Comment 1

[Florens Verschelde :fvsch]

Looking at the code (thanks devtools :)) it seems that background images were used in order to provide high dpi graphics: switching between controls.png and [e-mail].

Is there an accessible way to achieve the same result with <img>?
With srcset support (Bug 870021) that would be:

<img alt="Pin" width="24" height="24" src="controls-pin.png"
     srcset="controls-pin.png 1x, [e-mail] 2x">

But support might be a few months away at best? So a current-day solution would be nice.

Comment 2

[:Gijs (out for now; he/him)]

This is orthogonal to tiles development in principle, but I'm chucking it under there so people in that project are aware of it. Ed, want to give a verdict on how to prioritize this?

Seeing as we only deal with @2x images, we could theoretically solve it by duplicating the image and display: none'ing the relevant one using the media query. Ugly, but it would work, although you then get a new issue wrt how to handle events (that is, you'd most likely need a new level of nesting + a careful check you weren't breaking anything else by adding the nesting).

Comment 3

[Marco Zehe (:MarcoZ)]

Here's some background on why CSS background images are generally a bad idea for various accessibility reasons on actionable items such as buttons, and some possible solutions: https://www.ssbbartgroup.com/blog/2011/06/14/css-background-images-and-accessibility/

Comment 4

[Marco Zehe (:MarcoZ)]

Oops, didn't mean to remove the needinfo flag.

Comment 5

[Florens Verschelde :fvsch]

Support for srcset landed in nightly - Bug 870021
It would be a good idea to use it here. That’s one of the basic use cases for srcset, and it’s relevant dogfooding. :)

I’ll have some time next week and would be happy to take on this bug.

Comment 6

[:Gijs (out for now; he/him)]

(In reply to Florent Verschelde from comment #5)
> Support for srcset landed in nightly - Bug 870021
> It would be a good idea to use it here. That’s one of the basic use cases
> for srcset, and it’s relevant dogfooding. :)
> 
> I’ll have some time next week and would be happy to take on this bug.

Unfortunately, srcset is still preffed off by default. The bug tracking it being turned on by default is here: bug 1018389.

Comment 7

[Florens Verschelde :fvsch]

Yes, but it’ll be available in a few versions, so we could make a fix that will land at the same time.
I’m not sure implementing a non-srcset fix for just a few month is worthwhile, when this issue has existed for the past few years anyway.

Comment 8

[Justin Dolske [:Dolske]]

Seems like right fix here basically be what comment 0 alludes to -- make this pref not affect the browser's own in-content pages. I would expect this pref to only alter actual web pages, and not stuff that is actually part of the browser. Implementation details of New Tab versus, say, the Navigation Toolbar shouldn't matter.

Comment 9

[Ed Lee :Mardak]

Just a heads up that these images switched from a background image that was repositioned:
  background-image: url(...png
  background-position: -..px -..px;

to a background image rectangular slice in bug 1037341:
background-image: -moz-image-rect(url(...svg

I would assume the core issue of using background images still exists even with the new svg controls.

Comment 10

[Ed Lee :Mardak]

Is this still an issue now that we switched to svg and no longer have the hidpi css rules?

Comment 11

[Florens Verschelde :fvsch]

Attachment: Firefox 34 about:newtab with colors disabled

(In reply to Ed Lee :Mardak from comment #10)
> Is this still an issue now that we switched to svg and no longer have the
> hidpi css rules?

Yes, since the "disable colors" mode removes all `background-image`s.

Possible solutions would include, using (ideally) <button> elements and:
1. <img src="icon1.svg" alt="Label">
2. <img src="all-icons.svg#icon1" alt="Label"> (or possibly using <object> instead of <img>, depending on what Fx supports).
3. <svg><use xlink:href="#icon1"></use></svg> (requires inlining the SVG icons in a <defs> somewhere in the page).