Closed Bug 1008583 Opened 10 years ago Closed 6 years ago
[New Tab page] Invisible buttons with browser
.display .use _document _colors=false
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).
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 email@example.com. 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, firstname.lastname@example.org 2x"> But support might be a few months away at best? So a current-day solution would be nice.
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).
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/
Oops, didn't mean to remove the needinfo flag.
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.
(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.
Depends on: srcset-prefon
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.
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.
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.
Is this still an issue now that we switched to svg and no longer have the hidpi css rules?
(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).
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.