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 #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/

[gundulaniemann]

When a component is disabled, it might as well not be there. If a part is easily visible and ap art is not, this is unlogical and irritating.
If the control still has valuable information, the state 'read-only' should be chosen, not disabled.

[mbgower]

• visually associated text may be a way of describing this; programmatically associated is problematic (since a control can be implemented in such a way that an identical looking control could be constructed in different ways)
• we are considering "disabled" components (non-operable and non-navigable)
• in order to convey a read-only state (not updatable, but navigable), we need to meet text contrast yet still make discernable from the other states. So this becomes relevant as we consider what disabled is, versus read-only. Have a look at https://carbondesignsystem.com/patterns/read-only-states-pattern/ for some considerations

[giacomo-petri]

@giacomo-petri to create exampled in CodePen

[bruce-usab]

Discussed on TF call 12-6. Design tension between unavailable controls being "grayed out" (i.e., low contrast) but being important. Agreement that text labels outside controls must not be low contrast. @giacomo-petri offered to do some code pen examples.

[stevefaulkner]

code pen i developed for the article may be useful

https://codepen.io/stevef/pen/RwXZGYO

[giacomo-petri]

Recognizing the point raised by @stevefaulkner that labels are not affected by the disabled state of their associated inputs (except in cases where the meaning of the label is tied to the value or content of the input, such as with input type="submit"), I created a few examples to explore different scenarios.

These examples showcase how authors might customize colors and visual behaviors, particularly in cases where the label could be perceived by users as part of the input, aligned with the user interface component WCAG definition:

• radio buttons: https://codepen.io/Giacomo-Petri/full/vEBGepm
• input type text: https://codepen.io/Giacomo-Petri/full/zxOqEbv

When reviewing these examples, try to consider each scenario individually without making comparisons. Assume each example starting with a heading level 2 exists in isolation on a single page.

I believe that in scenarios where the label is visually integrated into the component, it may be clearer to present the label as visually disabled when the input itself is disabled. This approach somehow aligns with the perception of the label as part of the control, as described in the WCAG definition of a user interface component.

While alternative solutions may exist, and I recognize the importance of ensuring disabled options remain readable, there are situations where "visually disabling" the label, in my view, might not constitute a significant failure.

[alastc]

I can add a little background from what I heard of this exception from WCAG 2.0, and when it resurfaced for WCAG 2.1 (for non-text contrast).

So with second-hand info: The exception was added because not-allowing disabled controls to 'dim', created usability issues. People (disabled or otherwise) would try and use the controls, and get annoyed that they didn't work.
I don't think people working on WCAG 2.0 necessarily went through all the connotations that we've got in this thread, but broadly didn't want to enforce an approach that would create usability issues.

@scottaohara wrote:

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.

Indeed, but if you have the exception for one, you have the exception for all (user-interface components). I think it worked on the principle of a few scenarios not being covered was better than creating usability issues for everyone (in other scenarios). The other options is creating complex sub-clauses in the SC trying to capture all the nuances, but I doubt they wanted to go down that path.

When we were working on non-text contrast in WCAG 2.1, this came up again because there can be some sucky experiences with dimmed text and graphics. However, the same usability principle came up, and we didn't want to include something that mandated a poor user-experience.

We did discuss alternative approaches to dimming / low-contrast (e.g. adding icons), but it wasn't hard to come up with scenarios where these approaches fell down. We didn't have a good enough alternative to try and force contrasting text / graphics of inactive controls.

would this decision allow someone to dim the heading/group label if a section of disabled controls - e.g., a multi input date picker?

If that means a label / legend + 3 inputs, or the radio buttons example that @giacomo-petri created, then I think so. I think the label/legend of a control can be seen as part of the same UIC. I'm trying to mentally align this with the focus-appearance discussions where we were trying to work out the size of a UIC. That's where we came to "the unfocused component or sub-component" as the basis of size, because the radio-button + label would be a sub-component within the overall UIC.

Regarding the examples such as entire forms which the user doesn't have permission over, I suspect we'll have to include something along the lines of: Although you can use low-contrast text for inactive controls, there are some scenarios where this can cause issues...

This is a useful discussion for forming WCAG 3 guidelines as well, we can hopefully get some nuance in there.

[mbgower]

The themes that came up today in the TF call (intended to serve as something of a summary of this issue to date):

1. What is included in "inactive" in WCAG; does WCAG distinguish between read-only and disabled?
2. Technology limitations mean there can be no distinction between read-only and disabled, based on the element under consideration (e.g., radio buttons); for others, there is a separate read-only state. How does that affect this discussion?
3. The definition of user interface component (UIC) includes the notion of user perception as a determinant ("a part of the content that is perceived by users as a single control for a distinct function"), which is used to support the argument that a label or even help text could be considered part of the same control
4. WCAG 2.2 introduced a distinction between a UIC and its target ("region of the display that will accept a pointer action, such as the interactive area of a user interface component"), which has been used to refine this discussion (for instance, the label of a checkbox is part of its target in most user agent implementations)

[mbgower]

Regarding 1. What is "inactive"...
In the sense of a UIC component, I can find no normative content for WCAG that includes the word "disabled" or "read-only".

In the case of the two text contrast requirements (Minimum and Enhaced), the relevant exceptions are the same:

Text or images of text that are part of an inactive user interface component...

The language for Non-text Contrast is similar:

except for inactive components

In all three cases, "inactive" is undefined. Prior comments have pointed out various guidance in non-normative understanding documents, but I'm just clarifying that there is no normative wording on which anything definitive can be made.

I also could not find failure techniques (which while not normative, have a higher level of authority than other non-normative content) that used the words "disabled", "inactive" or "read only" (or variants) that were relative to text contrast failures.

Unless someone turns up other normative material, I do not think we can use existing requirements to authoritatively say that "inactive" is exclusively referencing disabled or that it includes both disabled and read-only.

Non-normative guidance can be provided; it's just that we do not have a strong foundation -- and yes, it would be great for WCAG 3 to better define this.