Content contributors: Kim Lanahan-Lahti, Digital Accessibility Coordinator, MNIT partnering with Minnesota Department of Transportation; David Miller, Senior Quality Analyst MNIT partnering with Minnesota Department of Corrections; Stephanie Waegener, Digital Accessibility Analyst, MNIT Office of Accessibility

As the State of Minnesota’s Office of Accessibility, we have a responsibility to uphold the State’s digital accessibility standard. Effective July 1, 2024, Minnesota adopted WCAG 2.1, Level AA as the required standard, replacing WCAG 2.0, Level AA.

WCAG 2.1 introduces 12 new success criteria, sparking valuable discussion among our Digital Accessibility Coordinators as they learn and implement the updates. 

This article summarizes a recent discussion about user interface (UI) components and how hover states are impacted by WCAG requirements, especially with new success criteria 1.4.11 Non-text Contrast. 

Learn the key principles and best practices for applying accessible hover states. 

Understanding UI components & their states

WCAG defines UI components as interactive parts of a web page—such as buttons, links, text input fields and form elements —that users recognize as separate controls with specific functions. These components must be operable and adaptable, allowing all users, including those using assistive technologies, to access and interact with them in ways that meet their individual needs.

UI components can have different states. WCAG defines a "state" as a dynamic property that describes characteristics of a component that may change in response to user actions or automated processes. States do not change the component itself but represent data tied to it or possible user interactions. Examples include:

• Default state: Original appearance on the web page.
• Keyboard focus state: Appearance when the keyboard action lands on it.
• Hover state: Appearance when the mouse hovers over it.

WCAG success criteria requirements

When a web page includes user interface (UI) components, those components must meet several WCAG success criteria. This helps users recognize the component as interactive and ensures they can identify when they reached it and can interact with it.

These WCAG 2.0 Level, AA criteria affect UI components — either in how they function, appear, or interact with users (especially those using assistive technologies):

• SC 1.4.3 – Contrast (Minimum)
• SC 2.1.1 – Keyboard (A)
• SC 2.1.2 – No Keyboard Trap
• SC 2.4.3 – Focus Order
• SC 2.4.4 – Link Purpose (In Context)
• SC 2.4.7 – Focus Visible
• SC 3.2.1 – On Focus
• SC 3.2.2 – On Input
• SC 3.3.1 – Error Identification
• SC 3.3.2 – Labels or Instructions
• SC 3.3.3 – Error Suggestion
• SC 3.3.4 – Error Prevention (Legal, Financial, Data)

 WCAG 2.1, Level AA adds these SC that directly impact UI components:

• SC 1.3.4 – Orientation
• SC 1.3.5 – Identify Input Purpose
• SC 1.4.10 – Reflow
• SC 1.4.11 – Non-text Contrast
• SC 1.4.12 – Text Spacing
• SC 1.4.13 – Content on Hover or Focus
• SC 2.5.1 – Pointer Gestures
• SC 2.5.2 – Pointer Cancellation
• SC 2.5.3 – Label in Name
• SC 2.5.4 – Motion Actuation

What about hover state?

WCAG does not require user interface (UI) components to have hover states. However, if a hover state is included, it must be accessible. Exactly how to meet that requirement can vary—and that’s what sparked a great discussion.

Here’s what we learned:

It’s a best practice to have visual consistency with UI component’s keyboard focus states and hover states. 

• Example: A "Sign in" button receives keyboard focus and the button’s color changes, along with an addition of a border on the button, offering two visual indicators. Ideally, the hover state would be designed to do the same or similar changes when the mouse hovers over the button.

When a keyboard focus has a visual indicator, it meets SC 2.4.7 Focus Visible (from WCAG 2.0). However, WCAG 2.1 introduced a new requirement, SC 1.4.11, that layers on to visible keyboard focus. Although SC 1.4.11 doesn’t require the focus indicator, when one is used and it's essential for the user to understand interaction, then it must meet the Non-text contrast ratio of 3:1 (don’t forget that any text on a UI component must also meet SC 1.4.3 Contrast (Minimum).

• In the example of the "Sign in" button, this means the button’s color change AND its new border must meet contrast requirements.
  • If the hover state has used the same design, and the visual indicators are necessary for the user to understand the change, at least one of the visual indicators must also meet non-text contrast.

An additional point was brought up that a keyboard focus color change should contrast with the default state of the UI component, if necessary for the user to understand the change. 

• A good example of when to use this is for UI components that show progress or a multi-selection answer. A user needs to tell how far along they are or how many answers they’ve checked.

If a hover state changes the mouse presentation (like an arrow to a text cursor) which are handled by the operating system/browser, it is exempt from WCAG contrast requirements. And it isn’t required to have an additional color change on the hover focus. 

• Even though high contrast color isn’t required here, designing for it makes the hover state more distinguishable and enhances the user experience. 

Note: Many WCAG criterion start with the assumption that people are using a modern browser, and the browser's default behaviors aren't overridden. For the examples above where hover state must meet SC 1.4.11, this assumption does not apply, as the default hover state is being altered.

Continued collaboration is key!

We only covered a few WCAG success criteria in this discussion related to UI components. But the list above had 21 total WCAG 2.1, Level AA criteria that directly or significantly affect UI components. We look forward to continuing these conversations, where we ask questions, challenge assumptions, and refine implementations. We best understand the nuances of these success criteria when we explore them together.

Whether you're a seasoned accessibility lead or just beginning to align your work with these standards, your insights matter. Through ongoing discussion, shared examples, and collaborative interpretation, we deepen our own expertise and shape a more inclusive digital experience for everyone!