SC 1.4.11 - Solid colour logo as link

[erikkroes]

Following a conversation in WCAG-Audit-Discussions/NL-BE#83 and during a video call, it was suggested to clarify this issue here as well.

The case

A logo has a single color and is being used as a link. The contrast with the background is low (less than 3∶1). Does this fail WCAG SC 1.4.11?

My impression

SC 1.4.11 has an exception for Graphical Objects, which includes logos.

Graphical Objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Graphical objects do not have to meet the contrast requirements when "a particular presentation of graphics is essential to the information being conveyed".
Het slaat op "User interface components" en "Graphical objects".

"Testing Principles" states:

Identify each user-interface component (link, button, form control) on the page and: ...

The definition of user interface component:

User interface components include form elements and links as well as components generated by scripts.
https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html#dfn-user-interface-component

My conclusion

I read that a link is a user interface component. I read that there is an exception for logos under graphical objects.
However, the link is a user interface component. It should not be assessed as a graphical object, and the exception does not apply. The logo fails 1.4.11

Possible solutions:

• Make sure the contrast is higher than 3∶1.
• Make the link meet 1.4.11 in another way with a border, underline or some other contrasty addition.
• Don't use the logo as a link.
• Compliance loophole: if the link is present elsewhere on the page, there's an alternative.

[JAWS-test]

From an accessibility point of view, that sounds good, of course, and I would welcome it if it were, but unfortunately I don't think the wording of the SC and 1.4.3 allows for that.

• In 1.4.3 there is also the logo exception and there is no distinction between text and text within controls.
• and in 1.4.11 a distinction is made between the graphics and the controls, but I assume that, for example, a toggle switch labeled with a graphic must be evaluated twice according to 1.4.11:

1. Status of the toggle switch (pressed or not pressed): Contrast of at least 3:1 (without any exception)
2. Labeling of the toggle switch: text or graphic - and then the logo exception applies in both cases

[erikkroes]

@JAWS-test Right. I think @yatil mentioned 1.4.11 is like 2 criteria in one. That aligns with your mention of evaluating twice. It would be evaluated as a User Interface Component, and as a Graphical Object. It could fail the first and pass the second (making it a fail for 1.4.11).

[JAWS-test]

Related: #1742, #1739, #1275, #902

[erikkroes]

Thanks for linking those.

Currently open issues were mentioned, but there seems to be no consensus. The conclusion of the video call was "we won't fail it", as a sort of status quo untill there was some sort of conclusion from posting it here. So I'd very much like a consensus and conclusion on this!

[RenateRoke]

@patrickhlauke can I conclude from the wording of the note it would still be a best practice, not a failure?

[patrickhlauke]

That's for the group to decide on, but generally "should" means "unless there's a good reason not to do it, it's a failure"

[GreggVan]

Not doing a should does mean that you have failed to do everything that was recommended. But sometimes things are should because they are a bad idea in some instances. Some things are made should because, under the right circumstances they might cause a requirement to fail. Those are not the only reason that something might be made a should - but they are two reasons that something might be a should instead of a requirement.

Documented Failures are not that many as a result.

But in any case - there was a reason something was a should instead of a shall (requirement).

In WCAG Failures have a particular meaning. That is:
a requirement is not met

We also have Common Failures that we document. But these need to be It is something, that

1. common enough to be worth documenting. Especially if it is because of misunderstanding or misreading of an SC.
2. an SC (requirement) is not met
3. if you do this -- the SC will always not be met - no matter what the circumstances are or what technology you are using
   • (to ensure this last one is true - Failures are often restricted to a particular technology where they are known to always be true failures - or even to specific circumstances under which they always fail, but it may not be recognized/seen.)

RE LOGOS Since they are not specifically mentioned as being included or excluded in the SC you would have to use the language of the SC and the way the LOGO was being used on the page, to determine if it does or does not qualify as having to have a contrast ratio of at least 3:1 against adjacent color(s):

[erikkroes]

@patrickhlauke Thanks for the feedback and the proposal!

You state:

for 1.4.11 the interpretation is also arguably already part of the normative wording (as a logo/logotype used for a link or button acts as a user interface control, which does not have an exemption).

If it is already part of the normative wording, wouldn't that clash with the usage of "should"?

I think people might read your writing as best practice or advice. "If the logo is a user interface component, you should ...."
While I think you meant to say something like: "When logos are used as interface components don't meet contrast requirements, you could do one of the following..."
I think a more explicit disctinction between the clarifcation (user interface components are not excempt) and the possible solutions would be more clear than the current proposal.