I'm having trouble understanding the WCAG 2.0 criteria 1.4.8.
From what I understand it basically says that if I have for example a <div> that I define both background and text color in, I will have to either:
Provide a color picker tool for that div so that the user can change those colors
"G156: Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text"
Providing a color picker sounds pretty far fetched, so I'm placing my hopes on "G156". Does a regular web browser (ie,firefox,opera etc.) qualify as such an user agent?
Another confusing part is the "common failure" where it says "F24: Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colors without specifying background colors or vice versa", which I sort of interpret as "as long as you specify both background and text color for that div, your safe".
Any thoughts on how to interpret this WCAG criteria?
Does a regular web browser (ie,firefox,opera etc.) qualify as such an user agent?
According to http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G156, it seems so. It says:
Tests
Procedure
Open the Web page in a browser that allows users to change colors of
HTML content.
Change the foreground and background colors in the browser
settings so they are different than
those specified in the content.
Return to the page and check that that the new specified foreground text
and background colors in the browser
override the colors specified in the
content.
Expected Results
Check #3 is true.
"as long as you specify both background and text color for that div, you're safe"
I think so. It means don't just assume the background is white, because if you don't explicitly specify it, it might not be.
Related
WCAG 2.1 introduced success criterium 1.4.11 Non-text Contrast for UI components like checkboxes, sliders etc.
Would it be safe to ignore 1.4.11 for the background-colour within a button, as long as the text inside has sufficient contrast as well to the button as required by 1.4.3 Contrast, as to the surrounding background colour?
Somebody who couldn’t perceive the button shape due to the low contrast, they would at least perceive the text within – just as with a text-only button.
And text-only buttons exist in several widely used design systems. As the text is the only thing left visible, and text needs a higher contrast than UI components, it automatically suffices for 1.4.11 as well.
Now, I’m not only wondering for the practical implications, but also for an audit. Do you know sites that passed audits with such buttons, or with text-only buttons?
Short answer, most likely you're ok.
Your interpretation is how I conduct my audits. If the button's background color does not have sufficient contrast compared to the page background color (or whatever color happens to be "adjacent" to the button background color) (1.4.11), then if the text within the button has sufficient contrast with the button background (1.4.3), then the user still has enough contrast to know where to "click". It's nice to know where the edge of the UI component is but it's not always necessary to know where it is in order to interact with the element.
The key is:
(1.4.11) Visual information required to identify user interface components
So if I can't tell where the edge of the button is, can I still "identify" where the button is? If there's sufficient text-to-background contrast (1.4.3), then "yes", so 1.4.11 doesn't fail.
Now, a lot of WCAG can be subjective and you might find an auditor that fails the button with 1.4.11 but just because one person says it fails (or another says it doesn't fail), doesn't mean that that person's interpretation matches with yours.
You might disagree with the auditor and that's ok, as long as you can back up your interpretation.
Do you know sites that passed audits with such buttons, or with text-only buttons?
Yes, I pass sites all the time based on my interpretation of this success criterion but I often give a "best practice" that the button edge should be distinguishable but note that it doesn't technically fail.
Is it good enough that all text+background combinations pass the level AA contrast guidelines in their default states (i.e. contrast ratio of 4.5:1)?
We have some links and buttons where the background changes opacity on hover/focus and this then doesn't pass the contrast check. Can anyone confirm if that's a problem or if it's acceptable so long as the default state passes?
It's a major problem.
If WCAG requires you to have a contrast of 4.5:1 between background and text color, it obviously applies to focused links which are the very first thing a user will want to read when tabbing around a web page.
I recently created a web page that uses HTML5 and CSS3 to draw a bar graph. This is my first time doing this, and I followed the instructions given here: http://www.htmlgoodies.com/html5/tutorials/bar-graph-with-css3-and-progressive-enhancement.html#fbid=gG6mmpDnQDn
The long and the short of it is to create a DIV tag for each bar and use CSS to set the size and color of each bar. Specifically, use the background-color CSS attribute.
This works great until the user prints the page, and I do expect the page to be printed many times.
The problem is that web browsers typically omit background images and colors from the printed version of the page. This results in the bars not printing at all!
Chrome allows the user to check a box indicating that background images and colors should print, but it isn't practical for me to say, "To print this, use Chrome and be sure to check that box yada yada yada."
One stop-gap measure I've deployed is to use CSS to specify that when the document is printed, a border should be drawn around the bars, but this is just a border; it doesn't fill the bar at all.
How can I make a bar graph with HTML5 and CSS3 that will print correctly under most browser configurations.
Add this style for Chrome:
:root {-webkit-print-color-adjust: exact;}
That reduces your user instructions to simply, "To print this, use Chrome."
Otherwise, you may need to resort to SVG like #MiltoxBeyond suggested.
I want to change the selection color of a multiple select element. I'm not talking about the background color in this answer, as this only changes the background color of the selected option (the selection color is still visible on top of that).
I'm aware this color is determined by the settings of your hardware, as shown in this question, but I was wondering if there was any way other than changing your system settings that can override this setting.
You could replicate the element with divs and such and program the logic with JS. This would give you complete control over appearance.
It's also not a great idea to ask your user to learn how to use new simple UI elements. You should consider the mobile compatibility, and maintenance of this code too.
Is there a reliable way to overlay an image over another image in a table-based HTML email? Keep in mind that, in order to render correctly, styles need to be inline.
Apparently the only way to have a bg image that works in all email readers is by specifying one for both the HTML background attribute of the body tag (for Outlook 2007, 2010) and the HTML background attribute of an HTML table that occupies the entire page (for all other email readers). It doesn't appear to be possible to have a bg image anywhere else that will display in all email readers.
Generally speaking the answer is "no". You can't overlay foreground content on top of other foreground content, and the options for adding a bg image are almost non-existent. But if you can manage with a single large bg image for the body tag (and table wrapper), combined with one or more foreground images, then "yes".
See: http://blog.mailermailer.com/2011/04/background-images-in-html-email-the-naked-truth/
Edit:
After running some exhaustive tests in Litmus, the answer is a resounding "no". Outlook 2007 and later only supports 2 ways to display a bg image: using the HTML background attribute on the body tag, and using the inline background-image style on the body tag. But in both cases, Outlook scales the image differently than other email readers, and there's no way to prevent the bg image from tiling.
For all practical purposes, in cases where it's important to support a wide variety of email readers:
There's no way to overlay images (or any other type of content).
Bg images are not supported.
From what I can gather backround images are not supported through all browsers. However, you may find this page from Campaign Monitor useful. At least it is quick to test the code to see if it suits your readers needs - check your email stats against which clients work before implementing if I were you.
I believe the above advice regarding "the only way to have a bg image that works in all email readers is by specifying one for both the HTML background attribute of the body tag" is also correct although Campaign Monitor seems to indicate otherwise. I would be careful to work out which browsers/email clients use the fallback and as to whether that would negatively effect your design.
As Z Index is supported except in Gmail (so perhaps not all that well), you could try to use that to create a design. Given that Gmail doesn't support it and the fallback is likely to be ugly as sin, you probably don't want to try this.