4 ms·
I agree we need to give accessibility more priority and we likely will once the discrimination lawsuits start rolling in. But this isn't an accessibility issue.
by jameslk 8y ago
I agree we need to give accessibility more priority and we likely will once the discrimination lawsuits start rolling in. But this isn't an accessibility issue. Nowhere in WCAG 2 will you find anything that explicitly outlines both color and background color need to defined in stylesheets.
This is for users who prefer dark themes who are overriding styles of websites incorrectly. It is a failing of the user's browser/OS for not explicitly overriding both background and color at the same time or neither. If every developer had to add in a color for the edge case that someone is overriding styles globally, then we'd be bloating stylesheets with extra unnecessary bytes.
- luuio 8y agoYou got it backward. The custom CSS of the website is overriding the system styles in this case. Let's take font-family for example. Just because you're setting the font for your input[text] tags doesn't mean the browser will also automatically set the font for other elements to match the style. If you want the website to have uniform look, then you'll need to set the font-family for other elements, too.
- jameslk 8y agoThis is really just the old debate of whether to use a reset css in disguise. It has nothing to do with accessibility.
- alistairSH 8y agoNowhere in WCAG 2 will you find anything that explicitly outlines both color and background color need to defined in stylesheets. WCAG doesn't specify implementation, but WCAG 1.4.3 does require a minimum contrast ratio[0]. If the site allows black text on a black background, it will fail that requirement. 0 - https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...