Closed Bug 1008583 Opened 6 years ago Closed 2 years ago

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

Categories

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

31 Branch
defect
Points:
3

Tracking

()

RESOLVED WONTFIX

People

(Reporter: fvsch, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(2 files)

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 controls@2x.png.

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, controls-pin@2x.png 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).
Blocks: tiles-dev
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → Disability Access
Ever confirmed: true
Flags: needinfo?(edilee)
Keywords: access
OS: Mac OS X → All
Hardware: x86 → All
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/
Flags: needinfo?(edilee)
Oops, didn't mean to remove the needinfo flag.
Flags: needinfo?(edilee)
Blocks: themea11y
Component: Disability Access → Theme
Flags: firefox-backlog+
Whiteboard: p=3
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.
Flags: needinfo?(edilee)
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).
Points: --- → 3
Flags: qe-verify?
Whiteboard: p=3
Blocks: 1050643
No longer blocks: tiles-dev
Priority: -- → P3
Component: Theme → New Tab Page
Depends on: 1051861, 1022592, 1022596
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.