Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

patrickhlauke
Copy link
Member

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

Copy link

netlify bot commented May 18, 2025

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...

QR Code

Use your smartphone camera to open QR code link.

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

@patrickhlauke patrickhlauke force-pushed the patrickhlauke-logo-logotype-exemption-note branch from be46563 to 60558b0 Compare May 18, 2025 18:55
graphical objects, 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 user interface components
(such as links or other interactive controls). In these cases, authors should choose

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@patrickhlauke patrickhlauke May 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@gundulaniemann gundulaniemann May 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines 401 to 409

Logos and logotypes are exempted from contrast requirements when they are purely used as

graphical objects, 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 user interface components
(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 user interface component
which serves the same purpose and does meet the contrast requirements.

Copy link

@erikkroes erikkroes May 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

@mbgower mbgower changed the title Add note about logo/logotypes to 1.4.3, 1.4.6, and 1.4.11 understanding Add note about logo/logotypes contrast to 1.4.3, 1.4.6, and 1.4.11 understanding May 23, 2025
@kfranqueiro
Copy link
Contributor

@bruce-usab
Copy link
Contributor

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
Copy link
Contributor

detlevhfischer commented May 24, 2025

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
Copy link
Member Author

patrickhlauke commented May 24, 2025

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
Copy link
Contributor

detlevhfischer commented May 24, 2025

@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
Copy link
Member Author

patrickhlauke commented May 24, 2025

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
Copy link
Contributor

detlevhfischer commented May 24, 2025

@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.

Co-authored-by: Alastair Campbell 


Text used as part of a logo or logotype is exempted from contrast requirements,

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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



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 user interface component (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 what the control's label is), or provide an equivalent user interface component which serves the same purpose and does meet the contrast requirements.

Copy link
Contributor

@alastc alastc May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@GreggVan GreggVan May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@patrickhlauke patrickhlauke May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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

@patrickhlauke
Copy link
Member Author

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
Copy link
Contributor

mbgower commented Jun 6, 2025

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants