F24: personal stylesheets may change the color at any level #4451
-
|
In technique F24, it's written some contradictory info : In the About part:
In the Description
Let's say the website has defined both the body and color: Here we have no problem of contrast. According to F24, the fact that main inherits from the body background-color makes the test successful. Now, if I want to use a personal stylesheet with my own CSS rule for the body I can override the default style with the following rule : I can no longer have a correct contrast between I use to test this using the |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
The point of F24 is that you can't make assumptions about browser defaults (going all the way to html/body/root) and just leave out definitions of both foreground and background colours as an author. That is all. Once a user comes in and applies their own custom stylesheets, it's then up to them (the users) to make sure their custom styles give them sufficient contrast. The point is purely that authors can't leave things out on the assumption that browser/user defaults are the same everywhere. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your answer. Just to be sure I understand correctly. In the example above, every definition for the body element gives the user a sufficient contrast. One is defined at the author level, and the other one at the browser/user level. What's not correct is the contrast between a subelement (the "main" tag) color, defined at the author level, with the parent background color, defined at the user/browser level I perfectly understand that requiring the author to set-up both background and color everywhere is not the goal here, but I can't find an use case where F24 would still be useful in real life. On one hand, the only way to redefine colors at browser/user level is mainly by overriding :root/body CSS rule. On the other hand, we say that having background /text colors defined at any parent level is sufficient. Side note : Firefox just removed the custom color/background color option they had. |
Beta Was this translation helpful? Give feedback.
-
|
the idea is that a user may have just defined their own preferred foreground or background, which differs from the author's assumed foreground or background/browser default (or the browser default may just be different on some systems ... like back in the day when the default unstyled pages were black text on gray, rather than black text on white). authors can't rely on defaults. that's all this failure technique says, effectively. if an author does forget to set both foreground and background, then they fail the contrast requirements. as this is unlikely to happen these days, it'll be rare to even come across this scenario though. |
Beta Was this translation helpful? Give feedback.
-
|
You're right, the scope of F24 refers to technologies that allow users to control colors “without overriding all author-specified styles.” However, modern platforms primarily support style overrides through CSS-based user stylesheets or system-level accessibility settings — which typically either fully replace styles (e.g., high-contrast modes), or selectively override them using CSS. These scenarios fall outside the scope of what F24 currently addresses, and clarifying this distinction would improve the technique’s relevance in today’s landscape. Don’t you think that F24 could benefit from some additional clarification? For instance:
|
Beta Was this translation helpful? Give feedback.
-
|
as a user, if i absolutely need those colours defined, i'd probably also need to start using |
Beta Was this translation helpful? Give feedback.
as a user, if i absolutely need those colours defined, i'd probably also need to start using
!importantin my definitions, exactly to make sure things cascade properly.