Add note about logo/logotypes contrast to 1.4.3, 1.4.6, and 1.4.11 understanding

[patrickhlauke]

While exempting text or non-text that is part of a logo/logotype makes sense (due to some companies' strict corporate identity requirements), it's nonetheless problematic when these logos/logotypes act as links of buttons.

These notes try to clarify the situation ... while for 1.4.3 and 1.4.6 these notes arguably add a new normative requirement (though using should), 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).

Closes #4376, closes #1275, closes #1739, closes #1742

x-ref #902

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	026ce0c
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/683a425b6e4bbf000844ba51
😎 Deploy Preview	https://deploy-preview-4402--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

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

[erikkroes]

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.

[patrickhlauke]

i intended it in the RFC sense

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

[patrickhlauke]

will discuss in the working group if we need to use stronger language (such as "authors must either choose ... or ...")

[gundulaniemann]

In fact, if the logo is visible by some contrasting parts, it should be sufficient if the text inside is given by an alternative like a tooltip. Where the tooltip should also explain the functionality.

[gundulaniemann]

Suggestion:
If the logo is used as an interactive component, ensure the component can be determined, either by contrasting parts inside the logo, by some outline, or by an additional text, to name a few options.

[patrickhlauke]

note that generally, you're not allowed to modify logos along the lines of "just put an outline around the logo's shapes"

[erikkroes]

Suggested change

	<p>Logos and logotypes are exempted from contrast requirements when they are purely used as
	<em>graphical objectsem>, under the assumption that they must comply with stricter color choices mandated
	by corporate identity guidelines.
	However, this is not the case when they also act as <em>user interface componentsem>
	(such as links or other interactive controls). In these cases, authors should choose
	a variant of the logo or logotype that has sufficient contrast, if allowed by the
	corporate identity guidelines.
	Alternatively, authors should provide an equivalent <em>user interface componentem>
	which serves the same purpose and does meet the contrast requirements.p>
	<p>Logos and logotypes are exempted from contrast requirements when they are purely used as
	<em>graphical objectsem>, under the assumption that they must comply with stricter color choices mandated
	by corporate identity guidelines. They are not exempt when they also act as
	<em>user interface componentsem> (such as links or other interactive controls).p>
	<p>When logos and logotypes are used as <em>user interface componentsem>, authors should
	choose a variant of the logo or logotype that has sufficient contrast, if allowed by the
	corporate identity guidelines.
	Alternatively, authors should provide an equivalent <em>user interface componentem>
	which serves the same purpose and does meet the contrast requirements.p>

I understand the value and meaning of should in RFCs. I hope this slight rephrasing and reformatting makes the text more explicit and understandable.

[fstrr]

Visually, the code looks like you want that update as two paragraphs, but there's only one set of

tags. Should it be one or two?

[patrickhlauke]

Noting that making this categorical statement will no doubt ruffle some feathers, as it "seems" to introduce a normative failure by the backdoor that some will argue wasn't as cut and dry there before...which is why I was treading lightly (in one of the linked issues there was some mention of "exempting logos was on purpose as it would lead to too many failures" or words to that effect)

[patrickhlauke]

happy to take it as additional suggestion to the WCAG 2.x backlog group though for further discussion

[patrickhlauke]

@erikkroes I updated your suggestion above for clarity (keeping the line breaks where they were, so it's clearer what your change is), and assuming you did want the first para to be actually split into two as well

[erikkroes]

I've opened this issue for clarification, so maybe I tread less lightly 😄

The split might not be needed indeed. I think it helped make my point in this conversation, but it should be fine without.
Thanks for picking this up and taking it further!

[kfranqueiro]

HTML diffs:

• Contrast (Enhanced)
• Contrast (Minimum)
• Non-text Contrast

[bruce-usab]

Discussed at length on backlog call 5/23. Group concurrence that when logo is part of a UIC, there remains the 3:1 contrast requirement. Concern that "should" is problematic, and Patrick offered to revisit.

[detlevhfischer]

This informal change would invalidate a long practice of exempting logos from contrast requirements, whether linked or unlinked. Many logos used are links to the start page. Often, there are other links (whether text of image) that replicate the function of the linked logo - but we have never passed logos that are below 3:1 only on the condition that there is, as it were, an in-page CAV.

So this looks like normative change to me if it is phrased in terms of a 'must' and not just as a 'should' (recommendation / best practice).

[patrickhlauke]

This informal change would invalidate a long practice of exempting logos from contrast requirements

I'd argue that for graphical/non-text logos at least, that practice was ... misguided, considering the distinction in 1.4.11 between graphical object and user interface component. for those, i'd posit that it's not a normative change, just a clarification of what should have been the practice all along.

for text contrast SCs, there is no UIC clause, so the (wrong, in my opinion) exception for "logotypes" is more problematic to address, which is why i was trying to tread lightly

in any case, i'm having a second round of tweaking/expanding the language following discussions at the backlog meeting to try and defuse the bomb

[detlevhfischer]

@patrickhlauke

…that practice was ... misguided

well, it is a practice covered in 1.1.1 for much longer than 1.4.11 exists - and I'd argue it is weird to demand another type or color for a logo once it is to be linked. Customers have wanted their logos the color they are and historically have been, many originating from a time when even 1.1.1 did not exist - which explains the exception.

[patrickhlauke]

well, it is a practice covered in 1.1.1 for much longer than 1.4.11 exists

where does 1.1.1 exempt logos?

assuming you meant 1.4.3 / 1.4.6, it only covers "Text that is part of a logo or brand name" so doesn't exempt any non-text parts of a logo

it is weird to demand another type or color for a logo once it is to be linked

is it? users need to be able to tell what they're about to click/activate ...

[detlevhfischer]

@patrickhlauke
oh yes, sure, I misremembered - it's 1.4.3 with the unqualified exception:

Logotypes
Text that is part of a logo or brand name has no contrast requirement.

[patrickhlauke]

if we're happy(er) with the rewording above - which includes a suggestion from @alastc - then this should be made to match

[alastc]

Suggested change

<p>Text used as part of a logo or logotype is exempted from contrast requirements, under the assumption that logos/logotypes must comply with stricter color choices mandated by corporate identity guidelines. However, this can be problematic when the logo or logotype also acts as a <em>user interface componentem> (such as a link or other interactive control). Some part of the control must meet the 3:1 contrast ratio so users can at least identify that there is a control. Authors could choose a variant of the logo or logotype that has sufficient contrast, include a border with contrast (though this may still not help users identify <em>whatem> the control's label is), or provide an equivalent <em>user interface componentem> which serves the same purpose and does meet the contrast requirements.p>

<p>Text used as part of a logo or logotype is exempted from contrast requirements, under the assumption that logos/logotypes must comply with stricter color choices mandated by corporate identity guidelines. However, this can be problematic when the logo or logotype also acts as a <em>user interface componentem> (such as a link or other interactive control). There are also contrast requirements for <a href="non-text-contrast">Success Criterion 1.4.11 Non-text Contrasta>, where some part of the control must have contrast, or an accessible alternative.p>

[alastc]

Something else occurred to me, sorry, which is that if we are talking about another SC, we should deal with it over there.

[GreggVan]

yes this also needs to be worded differently. This language puts an exception and rationale in a note -- which is not allowable. If it is an exception the exception needs to be in the provision and the rationale needs to use wording in the provision.

Eg something like this.

Note: Text used as part of a logo or logotype falls under the "essential" exemption because logos/logotypes often must comply with stricter color choices mandated by corporate identity guidelines.

Note: When the logo or logotype also acts as a user interface component (such as a link or other interactive control) other contrast requirements apply. See Success Criterion 1.4.11 Non-text Contrast.

and then include the proper note on logos as controls there.

[patrickhlauke]

This language puts and exception and rationale in a note -- which is not allowable. If it is an exception the exception needs to be in the provision and the rationale needs to use wording in the provision.

the note here tries to explain the exception (for "Logotypes") that is ALREADY in the normative SC wording. we're not introducing a new exception. or are you getting at something else?

"Logotypes
Text that is part of a logo or brand name has no contrast requirement."

[bruce-usab]

Discussed on backlog call 5/30, so far so good, but additional feedback is welcomed.

[patrickhlauke]

i mentioned it in this call the other week, but also note: 1.4.3 and 1.4.6 use the term "logotype", but likely in an inappropriate way. "logotype" usually refers to word marks, logos that are essentially made up just of text (albeit stylised, in a custom font, or similar). there, text is the ONLY thing that makes up the logo ... so don't assume that "if they can't see the text, then they'll be able to see the rest of the logotype" because there isn't anything.

i believe the spec should have just used "logos" rather than "logotypes" - logos can include both text AND non-text symbols.

[mbgower]

A few points, as a broad follow up to today's TF call.

1. I think the space we want to largely tackle the logo requirements, in regard to 1.4.11, has to be within the context of User Interface Components (not Graphical Objects).
2. I think we can put in some language on best practices, including the idea that most corporate logos exist in various forms, including black and white renditions which tend to have better contrast. However, there is already specific wording in the Understanding document addressing how logos are exempt via the essential part of the graphical objects clause.
3. Likewise, we should think about how that best practices wording could be reflected in some updates to the text contrast SCs, bearing in mind the logotype exception in place in 1.4.3/6.
4. I agree we can provide some possible techniques as examples within the Understanding document. But I also think this maybe would work better as a separate technique called something like "G###: Improving contrast for logos when used as user interface components". The reason I think this is that the Understanding document is already very long. With a distinct technique, we could mention it each time the logo exception is mentioned in the existing understanding document, and have a fairly small new section added. And then elaborate in detail in the technique. @gundulaniemann if you are game for this, I think you could run with creating a first draft of this techique, and have @patrickhlauke be your initial reviewer.
5. @patrickhlauke I'd like to get your thoughts on ways we can try to get more agreement on an approach in the issue(s) before moving to PR discussions? I ask this because when we spin these PR discussions into dozens (or a hundred) of comments, it makes it hard for someone reviewing the PR to quickly grasp the essentials. We can obviously address to some degree by putting in a summary in the main description after the fact (before it gets reviewed by the WG), but I wonder if there are ways of chasing nuance in the issue, where conversations tend to be better preserved?
   On the other hand, I get that if the topic only gets attention when a PR is generated, it makes for a conundrum!