Keep It Silly Simple
I sat down to review some code with my colleagues. It was clear that each of these solutions was heavily over-engineered. Each used custom web components, React, Angular, or other framework, and even basic HTML with aria added. All of them should get slimmed down and work to reduce or remove ARIA.
Comments closedWe previously discussed contrast under Guideline 1.4.3 Contrast. So why is there a second AA criteria for contrast? The earlier guideline covers only text. With the introduction WCAG 2.1, we need to start being aware of the contrast of graphical items, particularly active controls. But the way we test contrast for graphics is different than how we test contrast for text, kind of…
Just as we did in testing text contrast, we’ll need a contrast checker. There are many out there, but for this article I’ll be using Level Access’s Accessible Color Picker. The one you use may be different, but the concepts should be the same.
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
- User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
- Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
Technical words for technical people. Welcome to the world of writing standards!
“The visual presentation…contrast ratio of … 3:1 against adjacent colors.” Cool. We’re familiar with 3:1, we know how to use the contrast checker, let’s test!
There is a key phrase here that complicates the testing, “adjacent colors.” Our control must have a 3:1 contrast ratio against adjacent colors. Colors. How often have you tried to make a color palette with three colors that all have a 3:1 ratio? If you haven’t yet, it can be quite difficult. The more colors you add to the palette, the harder it gets.
But this adjacent colors is not expecting you to have a 3:1 contrast between all colors. The second bullet contains important information too. “Parts of graphics required to understand the content…” Of course there is more to it, but let’s start here. We’ll start with a simple button for a disclosure. Let’s get our example from WCAG.
This button has blue text on a gray button. The button has a darker gray border and sits on a white background. Most people will test the background color of the button to the white. And that is one way to do it. In this case, it will result in a false positive. First, because there is a border, the gray background is not adjacent to the white. So we measured the wrong thing. We need to compare the border with both the white background and the gray button background. This is because the border defines the edge of the control. This success criterion is about discerning actionable controls.
When we do this test, we find out that neither passes.
The border is #E1E1E1 and the gray only has a 1.127:1 contrast.
When the border is against white, it only bumps up to 1.308:1. But we’re not done testing this unit. We’ve checked the border against adjacent colors and it fails. But WCAG gave us an out that the W3C is using on their own site. “Parts of graphics required to understand the content…”. What is important to understand the content? Is it the background, the border, or is it something else, say the text of the button.
The text on its own has enough contrast against the gray. No additional graphic is needed to understand the control.
As seen in this image, the blue text against the gray has enough contrast to meet the 1.4.3 Text Contrast rules, and it still supports 1.4.11 despite the background failing.
When testing 1.4.11 non-text contrast:
Thoughts, questions, have a different method? Reach me on LinkedIn and BlueSky to discuss the topic!
1 CommentOne of the most common issues I see when testing is the content not having enough contrast. With 1.4.3, we’re focus on the contrast of text. This can be text in an image or just on the page. Later we’ll talk about the contrast of active controls in 1.4.11.
Designers commonly complain that they can’t design with the restrictions that WCAG has in place for contrast. At the same time the great designers love restrictions. So your reception will vary when you work with a designer. Remember, they don’t get a choice about adhering to the contrast levels set out.
Outlined in WCAG, we have two contrast levels we need to look out for text. We divide text into “normal” or “body” text and “large” text. Body text is all text smaller than 18 point and not bold. If it is bold, it can be as small as 14 point. Everything bigger than that is large text.
This is body text at 14 point.
This is large text, bold at 14 point.
This is large text at 18 point.
1 point does not equal 1 pixel.
1 point is actually 1.3 CSS pixels.
If you are like me, you are looking at those blocks thinking that they don’t look like 14 and 18 pixels. Heck, this body text looks the same size as the 18 point. Well that is because I use a larger than normal font for easier reading. Additionally, 1 point does not equal 1 pixel. 1 point is actually 1.3 CSS pixels. This means 14 point is really 19 rendered pixels. Eighteen point comes out to 24 pixels.
In Chrome and Firefox, the web inspector tools offer a “Computed” section. After highlighting the element in the code, switch to the computed tab and look for font-size. This will show the rendered pixel height regardless of what measurement you used to set the size. In addition to points, font sizes can be set with EM, REM, pixel, percentage, viewport height and width, just to name the most common.
Now that we know how to measure our fonts, let’s look at the contrast levels. We have two remember. One for body text and one for large text. For body text, the contrast ratio is 4.5:1. For large text the contrast ratio is 3:1. There are many contrast checkers on the market, so feel free to find one and use it.
My personal favorite is Level Access’s Accessible Color Picker for Chrome. Full disclosure, I currently work for Level Access. However, I’m not pitching the company. This color contrast tester not only provides the contrast and if it passes A, AA, or AAA, but is also helps guide you to fixing the colors.
On the side of the contrast values is a five by five grid. Your picked colors are in the middle. If you move up or down in the grid, options are shown for your background. Moving left or right in the grid changes the foreground. These options may have better contrast.
As a developer using this tool, I look for contrast pairs that don’t work. When I find an issue, I will suggest a color combo from these suggestions that does work. Then the designer just needs to approve, moving the process forward.
The WCAG is imperfect. It is a volunteer organization of hundreds trying their best to develop accessible rules the majority can agree on. On of the flaws is in the algorithm for finding contrast. There are combos that fall below WCAG standards that are no issue for people with color blindness. There are also combos that meet the criteria, but are unusable because they irritate eyes.
When the efforts to bring WCAG to the next level beyond 2.2, those involved began investigating other contrast algorithms. APCA is one of those. It looks like it will be how we evaluate contrast in the future. However, if you are building a website today it doesn’t matter. The current rules and laws all point back to WCAG 2.x and the algorithm used in that is not APCA. To comply with the current law, you must test colors under the current algorithm. This is true even if you use APCA to choose your colors. If you can use combos that pass both, you are future protecting yourself.
Have questions on this topic? Find me on LinkedIn and BlueSky to chat!
2 Comments
