1905845 - [WCAG, a11y] Custom color settings overwrite `fill` attributes of SVG elements

Status: NEW

(Firefox :: Disability Access, defect)

Description

[Hendrik Neumann]

Attachment: Pie with patterns Demo | Highcharts.com 2024-07-02 09-49-04.png

Steps to reproduce:

1. Start Firefox
2. Go to "Settings" -> "General" -> "Language and appearance"
3. Under "Colors" click the "Manage colors button"
4. Define custom colors for "Text and Background" and "Link colors"
5. Do NOT check "Use system colors"
6. In the "Override the colors..." dropdown select "Always"
7. Click "OK" and leave the "Settings" page
8. Open example page at https://www.highcharts.com/demo/highcharts/accessible-pie

Actual results:

The example page renders a pie chart SVG. However, the areas of the chart cannot be distinguished from each other, since they are all in the same color. The chart is not accessible and fails international a11y tests.

Inspecting the HTML in the Developer Tools shows that the fill attributes of the child elements of the SVG are set to window.

Expected results:

The areas of the chart should be rendered with different patterns that are accessible for users with visual impairments.

The fill attributes of the SVG's child elements should be respected and point to the pattern definitions via url(#highcharts-pattern-...).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

Core: SVG seems like the proper component to me.

Comment 3

[Jonathan Kew [:jfkthame]]

It's not really clear to me how best to handle this. In general, setting "Override the colors..." to "Always" is a clear request to use the specified colors instead of whatever the content calls for; how is the browser to know that in this example, it should still respect the SVG fill instead of replacing it with the user's chosen color? I suppose one heuristic might be to say that if the fill is not a solid color, then it should be kept unchanged; but that could leave unexpected bits of all kinds of colors as part of the pattern, which may be unwanted.

I'm moving this to Accessibility to seek some more guidance as to what the expected behavior here should be, though it may end up back in SVG once it's clearer what we should do.

Comment 4

[Eitan Isaacson [:eeejay]]

fill in general works with HCM and is not forced like other background-color. This seems like a highcharts issue, something in their pattern generator relies on element backgrounds to generate patterns, i assume. It's hard to make sense of it in their minified code.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:morgan, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Morgan Reschenberg [:morgan]]

I agree with eitan, sounds like they should be using forced-color-adjust: none or similar, if that's their desired behaviour. I'm not sure how we support patterns on a larger scale for HCM and SVG's. I think we have to rely on authors to express their intent via the media queries that are available to them to manipulate HCM/forced-colors experiences.

That said, if you see this as a larger a11y issue I'm happy to leave it in Disability Access until we have a better solution. I'll keep it in this component for now :)

Comment 7

[Monica Chiorean]

Marking as New as it reproduces on Win11x64 using Firefox build 130.0a1. If not correct please update. Thank you.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.