Remove note in F24 about css background images#4823
Remove note in F24 about css background images#4823patrickhlauke wants to merge 4 commits intomainfrom
Conversation
This short "in passing" mention in a note about CSS background images appears to introduce a whole new normative requirement by the backdoor, in a technique note, which effectively fails sites that don't provide both a background colour AND background image in their CSS, because users MAY have changed their browser not to load images. This is not covered anywhere else in WCAG, and in many other places WCAG explicitly does NOT care about how users may have modified/changed their browser settings. Not even 1.1.1 mentions the scenario as a particular reason/concern. This note oversteps its remit.
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
You also made a good clarification about foreground and background colors using images. Is it possible to leave in a recommendation to check for if CSS is disabled or images fail to load? The Robust part of POUR... |
that would make any use of CSS considerably more difficult to implement. and then would fail further if JS was also unavailable, so do we need to warn about that too? |
If the substance of F24 remains (that each and every element must have foreground and background colour specified) it would presumably also apply to elements where a background image is used? Or where is it written that in that case, background colour need not be specified? Checking contrast for text on background images, something that cannot be unambiguously tested automatically, certainly not across all viewport widths) would remain necessary even where the defined foreground/background colour pair passes. So I do not see anything in this note that introduces a new normative requirement by the backdoor. And therefore do not see the need to remove it. |
This part, arguably: "With background images, it is still necessary to specify a background color" [EDIT to make it clearer] This part is implying that it is necessary. That an author MUST do it. Which is an overreach, as it's not true. And the rationale given "because users may have turned off images" is not an explicit WCAG concern. I'd be amenable to keep that note, but to remove that specific bit, and expand on how testing would need to be done by checking the specific colours of the background image. (the fact that it can't be "unambiguously tested automatically" is interesting, but just shows how automated testing if flawed/falls short) |
|
as an aside, F24 is still a bit of a mess because it confuses things the background is not "inherited". if not defined, it's transparent, so the background of the parent/ancestor shows through. |
Hm. So would that become "With background images, it is still necessary to specify a background color if a foreground color has been defined"? Because if the default is being used, nothing would need to be specified? |
| Color and background color may be specified at any level in the cascade of preceding selectors, by external stylesheets or through inheritance rules. | ||
| </p> | ||
| <p> | ||
| Background color may also be specified using a background image with the CSS property 'background-image' or with the CSS property 'background' (with the URI of the image, e.g., 'background: url("images/bg.gif")'). With background images, it is still necessary to specify a background color, because users may have images turned off in their browser. But the background image and the background color need to be checked. </p> |
There was a problem hiding this comment.
Suggestion for last sentence:
ButBoth the background image and the background color need to be checked.
There was a problem hiding this comment.
Nevermind, I misunderstood that we are eliminating this paragraph!
| Color and background color may be specified at any level in the cascade of preceding selectors, by external stylesheets or through inheritance rules. | ||
| </p> | ||
| <p> | ||
| Background color may also be specified using a background image with the CSS property 'background-image' or with the CSS property 'background' (with the URI of the image, e.g., 'background: url("images/bg.gif")'). With background images, it is still necessary to specify a background color, because users may have images turned off in their browser. But the background image and the background color need to be checked. </p> |
There was a problem hiding this comment.
Nevermind, I misunderstood that we are eliminating this paragraph!
no my point with the "it is necessary" is that THAT'S what that paragraph is implying. it's not though. so that para is overreaching, making it sound like you MUST define a color in addition to an image if you're using an image. |
5 participants
This short "in passing" mention in a note about CSS background images appears to introduce a whole new normative requirement by the backdoor, in a technique note, which effectively fails sites that don't provide both a background colour AND background image in their CSS, because users MAY have changed their browser not to load images.
This is not covered anywhere else in WCAG, and in many other places WCAG explicitly does NOT care about how users may have modified/changed their browser settings. Not even 1.1.1 mentions the scenario as a particular reason/concern. This note oversteps its remit.
x-ref #4660 (comment)
preview: https://deploy-preview-4823--wcag2.netlify.app/techniques/failures/f24