Remove note in F24 about css background images#4823
Remove note in F24 about css background images#4823patrickhlauke wants to merge 8 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? |
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. |
…uce note about image backgrounds without apparent sneak requirement to set both a background colour AND an image
|
Revisited/expanded this: reworked this PR to only remove/amend the apparent normative requirement to define BOTH a background image AND background colour - replaced with a note about contrast testing. Further, this PR now corrects the inaccurate section about inherited color/background (background is not inherited - if not defined, an element has a transparent background, so what counts is that at least one of the ancestors of the element has a background |
Co-authored-by: Adam Page <adam@adampage.net>
6 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.
EDIT: reworked this PR to only remove/amend the apparent normative requirement to define BOTH a background image AND background colour - replaced with a note about contrast testing. Further, this PR now corrects the inaccurate section about inherited color/background (background is not inherited - if not defined, an element has a transparent background, so what counts is that at least one of the ancestors of the element has a background
x-ref #4660 (comment)
preview: https://deploy-preview-4823--wcag2.netlify.app/techniques/failures/f24