Add clarification to 1.4.11 Non-text contrast understanding about logos acting as user interface components - UIC needs to have *some* sufficiently contrasting aspect

[patrickhlauke]

For a counter-proposal, see #5133

The normative wording for 1.4.11 https://www.w3.org/TR/WCAG22/#non-text-contrast

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.

has two distinct aspects/subjects - user interface components (UICs) and graphical objects.

Logos that have insufficient non-text contrast are exempted when they act as graphical objects, as their (low contrast) colours fall under the "except when a particular presentation of graphics is essential" clause.

However, when logos are the only content inside a UIC, the logo itself may be exempt, but the UIC around it has no explicit exemption. A button/control only containing a logo with insufficient contrast, and no other sufficiently contrasting visual indicator, would fail the UIC clause of 1.4.11.

This means that authors would need to either choose a different version of the logo (if it exists) that has sufficient non-text contrast, or make sure there is some other visual indicator on the UIC so that people who can't perceive the low-contrast logo can still understand/see that there is a UIC to begin with.

The PR also adds a clarification/reminder that if there's an accessible alternative (such as a link/control that serves the same purpose) somewhere on the page that DOES have sufficient contrast, that can also be used to pass this criterion.

---

Follow-up to #4402 - this PR contains the more controversial aspect that clarifies if a logo is used as a user interface component, then the UIC does need to have a sufficiently contrasting element so that users can perceive it.

For 1.4.11 there is a wrinkle because the SC distinguishes between user interface controls and graphical objects. Logos on their own count as graphical objects, and if the CI/brand guidelines stipulated non-contrasting colours, then that is "essential". However, the "user interface control" part of a link/button with a logo is still subject to the requirements of the UIC needing to be identifiable.

Closes #4376, closes #1275, closes #1739

x-ref #902

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	8188411
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/6a2bd37745322c0008383ee8
😎 Deploy Preview	https://deploy-preview-5113--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[detlevhfischer]

Lastly, authors may instead consider providing an equivalent user interface component which serves the same purpose and meets contrast requirements.

This last option to conform provides an easy way out in many cases (all the sites with a link to the root page in the footer) so basically eviscerates this take on the normative text. If there is appetite for the change as suggested here, I would remove this option since a link in the footer does nothing at all to remove the issue that a linked logo (typically in the header) may not have sufficient contrast.

Having said that, I personally am in favor of a modified, clearer, PR #5113 - since the wording of 1.4.11 does not clearly spell out that logos lose their status as being exempt once they act as UIC (but I am repeating myself...).

[patrickhlauke]

This last option to conform provides an easy way out in many cases (all the sites with a link to the root page in the footer) so basically eviscerates this take on the normative text

however, that's the reality of conforming alternative idea, no?

a link in the footer does nothing at all to remove the issue

it makes sure that there's at least some way for a user who did not perceive the UIC to achieve the same result

[mraccess77]

The wording seems to allow a border to help meet the requirements - while identifying the control is actionable it doesn't seems to really address identifying the purpose of the control. I generally agree with the idea of an update to clarity this problem and how something needs to be done when a logo is also a control without an alternative control.

[patrickhlauke]

it doesn't seems to really address identifying the purpose of the control

unfortunately, i think that's as good as it's going to get while keeping within the bounds of the normative wording of the SC (and even this marginal improvement - that at least users can perceive that there's something there - seems to be controversial)

[baldino-m]

When talking about logos as user interface components, the only real-life examples coming to my mind are those of links, either as link to the home page (site header/footer) or some "Sponsors/Partners" section. In my opinion, if these "logo-links" don't contrast enough, the possible solutions are just two:

1. providing a "high contrast" version of the same logo, or
2. keeping the logo as it is and use borders/box-shadows or similar CSS styles to at least define the boundaries of the user interface component,

and these are not satisfactory.

Solution no. 1 just contradicts the logotype exception and its rationale, that is: the use of brand colours for this kind of graphical object is to be preserved. In my opinion, this is the only working solution if we want to enforce the non-text contrast, but companies will complain (with reason, since this was discussed and approved long ago. I just think that now it is too late to go back on this).

Solution no. 2 at least suggests that there is something on-screen, but this is not sufficient: in the worst case scenario of a very faint logo, this will look like a box with some blurry graphical content inside and no user will click/tap it. The point is that, in order to properly understand that this is a link, the logo must be recognized as such.

I am totally in favour of making the SC fail if the logo itself is not the original one but a version with very low contrast.

To summarise: I think the intent of this PR is good, but there is no real way of making this work without contradicting the "essential" exception, which, in my opinion, is just way too much for the real world.

[mraccess77]

I think SC would require borders for identification but likely can't require a logos being higher contrast if they are indeed lower contrast. So, I agree a note would be helpful to clarify this. I understand this doesn't address the full user need - but that can't be done in the framework of the current SC.

[gundulaniemann]

Still I suggest to also write that the alternative needs to be recognizable as alternative, usually by proximity, to yield an equivalent experience for all users.

[giacomo-petri]

I've had a number of conversations with colleagues and accessibility experts on this topic, and the opinions have been quite divergent, which seems to reflect where we are in this discussion as well.

To move the conversation away from purely theoretical interpretations, I put together a series of examples that simulate low vision, reduced contrast sensitivity, color vision deficiencies, and hyperopia. While these are only approximations and cannot perfectly replicate how individual users perceive content, they are nevertheless a reasonable approximation and useful for illustrating the practical implications of different approaches.

https://codepen.io/Giacomo-Petri/full/gbgORzp: as a baseline, consider a form where visible input borders help users identify which elements are interactive and need to be completed. In that context, sufficient contrast on the control itself clearly serves a user need: it allows people to perceive and interact with the form.

Now consider the specific scenario under discussion: a logo in the site header that links to the homepage - https://codepen.io/Giacomo-Petri/full/bNBPGym: my question is whether adding a border around the logo meaningfully improves usability. If the logo itself is not perceivable, does the presence of a border actually help the user? At best, it communicates that something exists in that area, but it does not communicate what it is, what it represents, or where it leads. Is that additional information genuinely useful to the user?

There is a similar example on the W3C homepage, where a collection of logos is displayed, some of which do not meet the 3:1 contrast ratio (you may need to refresh the page a few times to encounter it). These logos are not interactive, and therefore the example clearly passes the criterion as written. A screenshot is attached for reference:

However, imagine that the same logos were links to the respective company websites. Would adding a simple border around each logo (particularly one that may itself be difficult or impossible for users to perceive) meaningfully change the user experience? And more provocatively, does it really matter whether those logos are links or not?
If they are not links, then the issue is irrelevant. But if they are links, are we saying that adding a simple border suddenly resolves the accessibility concern?
That is where I struggle. The distinction appears to hinge entirely on logo operability, yet from the user's perspective the logo remains equally imperceptible in both cases. I find it difficult to argue that a border meaningfully addresses the underlying problem.
If the logo is not perceivable, does it really matter whether it is operable or not? And if the answer is yes, are we comfortable concluding that a thin border (even if arguably not the most appropriate solution) is sufficient to address the issue? Because that is effectively what this proposal implies.

When discussing accessibility with stakeholders who are not deeply involved in the field, storytelling is often an effective way to explain why a requirement matters. In this case, however, I find it difficult to construct a compelling user story around the proposed solution.
The story I would naturally tell is that the logo itself should be perceivable. If the visual representation of a brand lacks sufficient contrast, improving the logo would provide the most consistent and user-focused outcome. Unfortunately, logos have traditionally been treated as an exception, which largely removes that option from consideration.

This leads us to the main point of debate, which concerns two different interpretations of the normative wording:

• on one side, there is the interpretation that all user interface components require a visible 3:1 contrasting visual indicator
• on the other side, there is the interpretation that logos are exempt from contrast requirements, and that this exemption extends to user interface components whose visual representation consists solely of a logo.

I can see merit in both interpretations, and I think it is important to acknowledge that both are internally consistent depending on how one prioritises different readings of the normative wording. However, a decision still needs to be made in order to ensure consistent application in practice.

That said, I tend to favour the second interpretation. It feels more internally consistent; if a logo is explicitly exempt from contrast requirements, it seems reasonable that a UI element composed exclusively of that same logo should not be held to a different standard simply because it is embedded in a different context.
Otherwise, we end up in a somewhat peculiar situation where the logo itself may remain imperceptible, yet the issue is considered resolved by adding a contrasting border around it. I understand the rationale behind this approach from a strict reading of the criterion, but I struggle to see the corresponding user benefit or how to clearly explain it to stakeholders. If the primary content remains imperceptible, the border does not make the logo itself any easier to perceive; it merely indicates that maybe an element exists in that location.
Even putting that concern aside, there is a practical question: if the visual affordance itself is not perceivable, how likely is it that users will attempt to interact with something they cannot meaningfully see?

P.S. Once we reach consensus (or at least a democratic majority), we still need to resolve how this interacts with the exception:

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

A logo-link with no custom styling (default style not modified by the author) has no visual indication that it is a link. One could therefore argue that the author has not modified its appearance, and that it falls under this exception. That seems like another aspect that would benefit from clarification.

[detlevhfischer]

@giacomo-petri wrote:

if the visual affordance itself is not perceivable, how likely is it that users will attempt to interact with something they cannot meaningfully see?

In the common case where a logo linking to the home page is placed top left, the mere position acts as affordance - I may just see a faint blob but since it is up there, it's probably the logo.

[patrickhlauke]

@giacomo-petri

But if they are links, are we saying that adding a simple border suddenly resolves the accessibility concern?

it doesn't resolve the accessibility concern of the user not being able to discern what the logo is, but it does resolve the concern that the user may therefore not even be aware there is anything there to click/tap in the first place

[patrickhlauke]

and again, this to me still goes back to the way the normative wording is ... worded. the exemption is only written out for graphical objects, not for user interface components. the argument with these two PRs boils down to "even though we didn't explicitly write it as such, we actually meant the exemption to apply to both, even though we only wrote the exemption for one"

(if the idea indeed was that the exemption was meant to apply to both mantles/aspects, then really that would warrant a normative rewording of the SC... but i know that this idea of touching normative wording is taboo)

an additional thought: while the discussion (and indeed the PRs) has been focused on logos, there's other graphical objects that are exempt ... such as country flags. would the same vehement defense apply to cases where flags act as controls, but have insufficient contrast? (this makes me think we probably want to tweak/expand the rationales provided in the notes to be more general and cover those types as well)

[giacomo-petri]

I don't fully agree with the distinction that option 1 is a valid interpretation of the normative wording, while option 2 necessarily deviates from it. IMO both options are attempting to resolve a situation that is not explicitly addressed by the normative text without deviating from it.

In the specific case of a logo-link, the same graphical object serves a dual role: it is both the graphical representation of the user interface component and a graphical object that falls under the exemption defined in SC 1.4.11. While the link itself is the user interface component, the only visible representation of that component is the logo.

If the rationale for requiring contrast is that users must be able to identify the presence of a control, then it is not self-evident that a generic border achieves that goal in all cases, particularly when the graphical object that visually represents the control remains imperceptible.

For instance, this seems different from cases such as a labelled form control, where the label provides meaningful information about the control while the boundary helps identify the interactive region. In a logo-link, by contrast, the graphical object itself constitutes the sole visual representation of the component, so the relationship between the exempt graphical object and the identification of the control is less clear. Unlike cases where visual information is distributed across multiple elements, here both the representation of the content and the visual affordance of the component are embedded in a single graphical object that is itself exempt under 1.4.11.

That said, even going in the direction of option 1, there is a change in this PR that states: "authors must nonetheless make sure that there is an aspect of the user interface components that allows users to identify the components". However, this still does not address my post scriptum note:

P.S. Once we reach consensus (or at least a democratic majority), we still need to resolve how this interacts with the exception:

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

A logo-link with no custom styling (default style not modified by the author) has no visual indication that it is a link. One could therefore argue that the author has not modified its appearance, and that it falls under this exception. That seems like another aspect that would benefit from clarification.

[awkawk]

Adding these links in where the WG responded to questions about adding logotype in as an exception explicitly but felt that it was covered.

w3c/wcag21#875
w3c/wcag21#709

And yes, the essential exception is in the graphics part of the SC, but I strongly believe that the WG would not have allowed a logotype an exception to contrast in the second half of the SC after requiring it in the first half.

[patrickhlauke]

I strongly believe that the WG would not have allowed a logotype an exception to contrast in the second half of the SC after requiring it in the first half

sound exactly like something that should be clarified in a normative erratum...

[patrickhlauke]

Superseded by #5249