The Web Content Accessibility Guideline’s (WCAG) Success Criterion 1.4.11 Non-Text Contrast is one of the harder to understand requirements. Here’s a deep-dive into the details of it, including practical examples, concerning only its “User Interface Components” section.

Because, of course, this SC has multiple sections:

Rewriting this Success Criterion for UI components only could look like this:

Visual information required to identify user interface components and states must have a contrast ratio of at least 3:1 against adjacent color(s), except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author.

A practical example

Oliver Schöndorfer, who runs Pimp My Type and its associated YouTube channel, posted the following image to LinkedIn recently, accompanied by the question:

Does this pass WCAG 2.2 color contrast, dear #A11Y and UI design folks? I’m relating to Success Criterion 1.4.11.

The question is (in my words): If a UI component has a border and the contrast is at least 3:1 against only one side of the border, does the UI element still meet WCAG SC 1.4.11 Non-Text Contrast?

To be able to demonstrate how to apply the success criterion, I have recreated the form in HTML and CSS (Codepen):

I tried to stay true to the original without being pixel perfect. I also had to guesstimate the colors from the compressed social media JPG. In the end, I decided to use the following colors:

• Border color: #9b929b
• Input background: #ffffff aka white, a contrast of 3:1 against the border
• Dialog background: #f8f3e2, which has a contrast of 2.7:1 against the border

With this groundwork done, we can dive into seeing if the form fields meet the minimum contrast requirements of WCAG. Notice how we don’t even look at the question Oliver posed for quite some time, as we first need to look into the possibility that this Success Criterion doesn’t even apply:

Does it meet exceptions?

The first step of seeing if a Success Criterion even needs to be looked at is to check exceptions. If the UI component (in this case) is covered by an exception, it’s an automatic pass, and we don’t need to think about it further. Let’s remind ourselves what the exceptions are in this case:

…, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author.

Inactive component?

The graphic does not provide us any information about the interactivity of the input fields. It’s unclear if they are “inactive”, but I think for the question to make most sense, we can assume that this is an active login form. This exception does not apply.

As a reminder: Inactive components in HTML are inputs that have the disabled attribute or are made to work like a native component that has it – no mouse or keyboard or other interaction, and no inclusion in the accessibility tree.

User agent component?

This exception is very narrow, and its goal is to cover UI components where developers have no influence over the rendering (let’s say a native file or color picker). Sometimes developers can also take standard components to prototype, or for quick development of unexpected functionality. However, once you modify the UI element in any way, you’re on the hook for the proper color contrast, this includes changing the color of the text.

In our case, this exception also does not apply, as the input forms are designed (colors, borders, rounded corners).

What visual information is required?

That leaves us with the rest of the requirement:

Visual information required to identify user interface components and states must have a contrast ratio of at least 3:1 against adjacent color(s), …

The question that we have to ask ourselves is: Is the border visual information required in the context it is in? In most ordinary forms, I would say that this is the case. Where to click and see where form fields are is essential to filling out the form. Forms are usually not universally designed: Sometimes an associated field is below its label, sometimes next to it, and occasionally the form field is above the label.

But this is a very specific form: A login form. And it is in a dialog. As Patrick H. Lauke wrote in a LinkedIn comment (slightly edited for clarity):

Even if there was no contrast between the border and the inner and outer colour, it would arguably pass because the placeholder text there gives a hint that there’s an input field. So there’s no hard need for the border to identify/perceive the presence of the field.

To demonstrate this, I’ve removed all color from the login form:

Without the border, the placeholders together with the labels and the positioning act as the visual information to identify the form fields. The border isn’t even needed, so we would determine that this passes the Success Criterion. This is why the context is critical, and also why it is so tough to automate accessibility.

Just to be clear: Passing WCAG does not mean that it is a good design. It just means that you did meet the lowest bar.

Removing the placeholder text

In accessibility, we generally argue against placeholder texts, as demonstrated by this placeholder text research by the Low Vision Accessibility Taskforce of W3C. And while placeholders have the most impact when they are replacing labels, in this instance they are completely redundant to the email and password labels.

If we remove the placeholder, it becomes much less clear where to click. Yes, the most likely position of the form fields is underneath the labels, but that would be a pure guess, and guesswork like this means that the visual information required to identify the UI component is missing.

So this is when Oliver’s question becomes relevant! We’ve identified that the borders are indeed the “visual information required to identify” the UI component if there are no placeholders. With colors and borders added back in, it looks like this:

Next step! The requirement says that the UI component must have a contrast ratio of at least 3:1 against adjacent color(s).

One misunderstanding that I have seen in the LinkedIn comment underneath Oliver’s post was the assertion that the border must have a minimum 3:1 contrast ratio against both, the background of the input field and the background of the dialog. If that was the case, this would fail because we (deliberately) picked one color that is less than 3:1.

But this is not what WCAG requires (as the bare minimum) here. The border is not the UI component, the input field is, so this is about colors adjacent to the input field. Because WCAG is written in a way that works for all technologies, it does not care about where the CSS for the border is actually applied to:

An <input> element with a border would be judged the same as a border-less <input> element with a <span> around it, where the border CSS is applied to the <span>. It’s always about how the complete control is perceived by a user.

To be conforming, we look for a 3:1 contrast edge. That edge is there between the background of the input field and the border.

The easiest way to verify that it’s a sufficient edge is to “level out” non-conforming colors. The dialog background color and the border color could be the same color (with a contrast of 3:1 to the input field background) as far as we’re concerned, it would not change how we determine conformance. Colors with less than the minimum contrast are always insufficient, no matter if that contrast is 1:1 (same colors) or 2.99:1 (different colors).

So with the dialog background color being the same as the border color, we get this outcome:

Because the input fields are easy to recognize here, we can be sure that they conform to WCAG. (Yes, in this demonstration, the contrast of the text does not meet the contrast ratio, but this is irrelevant for finding out the impact of the border.)

Why does it say adjacent color(s)?

Depending on your use case, you might have several adjacent colors instead of one. Imagine the input fields had a background gradient for some reason. Some adjacent colors would be insufficient. This can make the determination if a user interface component meets WCAG much more complicated. (And you thought this was already a long article!)

In that case, you would mostly do the same as above but for every color change: If the color change is insufficient, you disregard it and “level it out”. Then you look at the resulting shape: Would it be possible to recognize the user interface element? Then it passes.

Is this good design?

WCAG does not define what good design is. Its goal is to have Principles and Guidelines that guide you towards an accessible result. The Success Criteria are guardrails that make sure you’re not completely on the wrong track. (See: WCAG 2: Guidelines and Guardrails)

In most cases, doing the bare minimum is not making it particularly easy for your users to interact with your content. It only ensures that people with disabilities are not entirely shut out. I would recommend always using a more contrasting color for the border, and also suggest using a 2 pixel wide border:

Some additional considerations

If you can, optimize the design before implementation. That includes the positioning of the links for creating an account and requesting a new password. In the design above, they are underneath the “Continue” button, which means some users that navigate through the page linearly with the keyboard or screen readers don’t encounter them until after the form has already effectively ended with the “Continue” button.

To make these links easy to discover, I put a link next to the login heading that says, “or register”. The “Forgot password?” link is put directly after the password field. In addition, I reinstated the underlines on the links and used CSS text-underline-offset to allow for a little more breathing room between the link text and the underline.

Avoid putting form related information after the submit button of a form, common instances where this happens are coupon code fields or terms and condition checkboxes. All information to complete a form must be available before submitting it.