✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	6508a34
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/684d9aef994fb8000845035b
😎 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.

HTML diffs:

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

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.

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

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

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

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

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

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

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.

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!

Reworded/reworked this into a new suggestion, seeing the pushback the original suggestion got:

• for non-text contrast, clarified what the absolute minimum requirement seems to be - having "something" that at least helps indicate that there IS a UIC (even if you can't tell WHAT it is)
• still added clarification of when a logo may NOT be exempted (if the presentation of the logo is down to author choice, not corporate identity/brand guidelines)
• for text contrast, can only make it a best practice suggestion

for clarity, the "author choice" thing would be things like this mockup here ... say a conference site chooses (because it looks "sexy") to have sponsor logos super faint (and then on hover, they become properly visible)

that presentation is not "essential", it's not because the corporate id mandated it ... it's because the author chose to do that. and THAT is not exempt, I would claim.

Direct links to the previews

• https://deploy-preview-4402--wcag2.netlify.app/understanding/contrast-minimum
• https://deploy-preview-4402--wcag2.netlify.app/understanding/contrast-enhanced
• https://deploy-preview-4402--wcag2.netlify.app/understanding/non-text-contrast

If logos are presented with an insufficient contrast, but their presentation was an author choice rather than
being mandated by corporate identity or brand guidelines, then that particular low contrast presentation is
not "essential", and the logo is not exempt from the contrast requirements.

Author choice or not? I fear this will often be an impossible call to make, at least for auditors, when they have no direct access to corporate style guides or policies, or designers' deliberations.

I still do not see how being linked (which logos very often are, and have been, as part of site navigation) invalidates the essential exception in 1.4.11 for graphical objects. If it should invalidate it, that should be spelled out normatively in the exception, not sneaked in via a note. The fact that UIE and graphic objects stand separate in 1.4.11 and the first does not explicitly limit the exception of the second leaves ambiguity, but in the face of such ambiguity I prefer avoiding a stealth normative change unless such a change is agreed by the WG (even as substantive errata) and embedded in the normative text (in which case I fully support it).

As a mere side comment, im many cases the larger size and the overall gestalt of the header with the conventional top left position of the logo as well as the general rule of thumb that activating "that blob top left" takes you to some landing / start page, all contextually support logo identification and seem to reduce the practical user impact of low contrast in logos.

I still do not see how being linked (which logos very often are, and have been, as part of site navigation) invalidates the essential exception in 1.4.11 for graphical objects.

the graphical object is exempted, but the user interface component that wraps the logo isn't exempted. so you can keep the faint logo, but there needs to be some way for the user to understand the presence of the actual UIC (i'd love to be able to go further and actually invalidate the exemption for the graphical object part in this case, but ... at the very least, users will know that there IS a UIC there, even if they still can't discern WHAT it is)

As a mere side comment, im many cases the larger size and the overall gestalt of the header with the conventional top left position of the logo

you seem to be fixated on the idea that this is aimed at somehow punishing the logo in the top left of the header. when really this is more about cases where authors have gleefully done "design" on logos on the main page, like those "here's a list of all our sponsors" / "these are the clients that use our product" / etc

Author choice or not? I fear this will often be an impossible call to make, at least for auditors, when they have no direct access to corporate style guides or policies, or designers' deliberations.

ok, so you do an audit, you as an auditor think "surely this visual treatment of the logo is not mandated by their CI, so i'll flag it". the client, upon receipt of the assessment, tells you "actually, our CI forces us to do this" and you change the fail to a pass...

and if you're an author (the other audience for these guidelines), you are told here that just because it's a logo, it doesn't mean you now have carte blanche to do whatever you want.

@patrickhlauke lets just see what the rest of the group will say—it is not a molehill I intend to suffer on