Does the SC 1.4.3 Contrast minium exception apply to text outside a disabled control?

[jha11y]

For the "Text or images of text that are part of an inactive user interface component" exception for WCAG 1.4.3 Contrast (Minimum), does the exception apply to the label for a control when it is outside of that control?

For example, a radio button that is disabled, does the text label does have to meet the contrast requirements of SC 1.4.3?

Would the exception apply to "helper text" (text underneath a text input field)? Error messages positioned like helper text?

I did check the other WCAG GitHub issues to see if my question had been answered, but I did not find this exact question. I know text inside a disabled control (e.g., HTML button) would be exempted.

[JAWS-test]

I assume that the exception applies to all labelling and descriptions that are related to the deactivated control. However, it should be noted that the exception is problematic if the deactivated elements convey relevant information (see https://github.com/w3c/wcag/issues/869). This means that even if the WCAG does not require contrasts in this case, the minimum contrasts of 4.5:1 or 3:1 should be met.

[jha11y]

@JAWS-test I did review #869 But it did not seem to answer my question specifically about text outside of the control.

I agree minimum contrasts should be met (4.5:1 or 3:1), but I looking for backing on that decision as we are trying to enforce this a my company, but are getting pushback.

[JAWS-test]

@jha11y As I said: With reference to the WCAG, it is probably not possible to justify that deactivated elements and their texts (inside or outside) require sufficient contrast. That's why your company's resistance to contrasts is understandable.

However, if the disabled elements convey relevant information, then the contrasts should be met, even if the WCAG does not require this. The WCAG is not perfect and unfortunately does not cover all areas of accessibility. That's why it is constantly being developed further.

You can easily check whether deactivated elements convey relevant information: What happens if you completely remove the deactivated elements from the page. If everything is OK then you don't need sufficient contrast. Or does removing it result in a loss of information? Then the contrasts for the information should also be taken into account.

[mraccess77]

Sometimes inactive controls may actually be actionable and I would argue would be covered in those cases. For example, Apple Watch has alarms that are inactive but can be activated by the user.

[JAWS-test]

@mraccess77

Sometimes inactive controls may actually be actionable and I would argue would be covered in those cases. For example, Apple Watch has alarms that are inactive but can be activated by the user.

What you are describing is something different and has nothing to do with deactivated elements: A deactivated element is an element that cannot be operated (with mouse and keyboard) and does not receive the focus.

Your element is an operable element, a toggle that switches something on and off in the application. In other words, it is not the switch that is deactivated, but the switch that deactivates a function. However, the toggle switch itself is always operable and accessible and must therefore comply with the minimum contrasts.

You are correct, however, that the toggle switches that are in the off state are often designed to look like deactivated elements. This is a design error.

See: https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum#inactive-controls

[giacomo-petri]

According to the understanding document:

User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements. An inactive user interface component is visible but not currently operable. An example would be a submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.

user interface component is defined as:

a part of the content that is perceived by users as a single control for a distinct function

Note Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.

Note User interface components include form elements and links as well as components generated by scripts.

Note What is meant by "component" or "user interface component" here is also sometimes called "user interface element".

From my perspective, both the input field and its associated label are part of the user interface component.

If my understanding is accurate, it might be beneficial to enhance clarity within the understanding document by providing an example alongside the simple disabled button (I can do that if there is consensus).

[alastc]

From the informal TF meeting, we agreed that separate text labels that are part of the same control would pass. However, we are not enthusiastic about providing an example of this. @giacomo-petri will draft a summary which we can then get agreement as an official response.

[giacomo-petri]

Proposed (draft) response:

---

According to the 1.4.3 Contrast (Minimum) Understanding Document:

User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements. An inactive user interface component is visible but not currently operable. An example would be a submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.

the term user interface component is defined as:

a part of the content that is perceived by users as a single control for a distinct function

Note Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.

Note User interface components include form elements and links as well as components generated by scripts.

Note What is meant by "component" or "user interface component" here is also sometimes called "user interface element".

Therefore, an input field along with its label is considered a single user interface component. As a result, the label itself is not required to meet minimum contrast ratio requirements.

That said, this is not considered a best practice, and it is preferable to ensure the label remains easily perceivable. Therefore, no examples of this will be included in the understanding document.

[jha11y]

Thank you all for the clarity

[scottaohara]

I’m not sure I agree with the outcome of this discussion. Especially since the understanding doc references html controls as the rationale, but the separate labels for most html controls don’t get dimmed by default. It’s telling, to me, that a disabled button is used as the example since that’s one of the few controls where the label exists within the control and thus would need the contrast exception.

Consider an interface where toggling the checked/selected state in one section of the UI disabled controls in another section. These disabled controls should still have labels that can be read, as that might inform the user that their prior selection that disabled these controls was in error.

But as another point of clarity, would this decision allow someone to dim the heading/group label if a section of disabled controls - e.g., a multi input date picker? The argument here being that the user might perceive these separate controls as one ui component.

For context, I can point to a number of products where the primary ui is disabled form fields unless the user has been given permission to or has enabled editing. But that doesn’t mean the user doesn’t need to be able to read the labels of the form fields. Rather, it’s quite important that they can, as it can help inform them as to whether they should edit that particular set of fields, vs another

[giacomo-petri]

I believe there are several scenarios that this SC does not cover, and the ones you've highlighted may be among those unaddressed scenarios.

Consider an interface where toggling the checked/selected state in one section of the UI disabled controls in another section. These disabled controls should still have labels that can be read, as that might inform the user that their prior selection that disabled these controls was in error.

Although different, a similar principle applies to sets of disabled buttons that depend on a prior action. These buttons (and their labels) can be essential for users to understand potential actions or options. However, according to this SC requirement, they are not required to meet minimum contrast standards.

I recently encountered an example in a one-page checkout flow where payment methods were shown as disabled expandable/actionable buttons until the shipping information was entered. This design meant that some users needed to fill out all the required shipping details before they could see which payment methods were available, whereas others could quickly spot their desired payment method by glancing at the low-contrast disabled buttons. For instance, I quickly recognized that PayPal was unavailable, which may have made me hesitate right from the start, but this wasn't immediately clear to other users.

But as another point of clarity, would this decision allow someone to dim the heading/group label if a section of disabled controls - e.g., a multi input date picker? The argument here being that the user might perceive these separate controls as one ui component.

This is part of the ambiguity around what is "perceived by users" in the user interface component definition. For example, in a set of radio buttons within a fieldset/legend structure, even though a group of items might result in a single final choice, each input is an individual entity (clicking a radio button or its label selects that specific input). Thus, in my opinion, the legend or headings aren't part of the control itself, but again, it might be subjective. The labels, on the contrary, enable interaction with the inputs (of course if programmatically associated with native HTML markup).

---

That said, @scottaohara, I understand and share your concerns about the importance of having discernible labels, regardless of the input's state, and I agree with your perspective. Given the current definition of a user interface component - "a part of the content that is perceived by users as a single control for a distinct function" - there’s likely room for further clarification no matter which direction we decide to take, especially since "perceived by users" is subjective and open to interpretation. This is even more accentuated in my opinion by the NOTE 1, since a screen reader user indeed would perceive a component as the resulting relationships between elements based on how they are coded.

I'm now also considering how the definition of "user interface component" applies to other success criteria. For example, the SC 4.1.2

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; ...

It doesn't quite make sense to include the label in the user interface component definition. What would it mean? While the user interface component needs a name, the label itself (in the context of an input with a label) doesn't require an accessible name. Additionally, if the "group of items perceived by users as a single control for a distinct function" includes both the input and the label, that creates further confusion. Definitely, it's the input that needs an accessible name (which can be provided by the label.)

I’d like to retract my previous statement. However, if we decide to proceed with the Scott's suggestion, I believe we need to do more than just respond to this thread with a TF response. We should enhance the understanding document by clarifying what is exempt and what is not, along with providing concrete examples. In my opinion, this should include a general explanation of why, for instance, a set of disabled buttons that convey information solely through their content is exempt, whereas a set of disabled radio buttons, where the "associated" labels are not, is treated differently.

[scottaohara]

Thanks for the response @giacomo-petri, I appreciate the context you provided, but also that you understand my pov and acknowledge there may be more to do here than just this response, regardless of what the final decision ends up being.

[stevefaulkner]

I don't think it does as user agent styling for disabled controls do not confer a dimmed state for label text. test case

[bruce-usab]

A bit off-topic, but I thought this conclusion is something we might use elsewhere:

...That said, this is not considered a best practice, and it is preferable to ensure the label remains easily perceivable. Therefore, no examples of this will be included in the understanding document.

We have, so far, resisted pass-but-terrible examples. That is a pithy explanation!

[stevefaulkner]

I am doing a deep dive on this and will respond in detail ASAP

[stevefaulkner]

I have taken a look at disabled HTML controls and how they are displayed: https://html5accessibility.com/stuff/2024/11/04/disabled-and-obscured/