Skip to content

2026–05–22

Kenneth G. Franqueiro edited this page May 22, 2026 · 1 revision

Minutes from meeting on May 22, 2026

Attendance (11): Gundula Niemann, Patrick H. Lauke, Baldino Morelli, Bruce Bailey, Filippo Zorzi, Francis Storr, Giacomo Petri, Scott O'Hara, Ken Franqueiro, Jonny James, Lori Oakley

Drafted

  • #5113: Add note to 1.4.11 Non-text contrast about logos acting as user interface components
    • This was the more controversial part that was split out of #4402: Add note about logo/logotypes contrast to 1.4.3, 1.4.6, and 1.4.11 understanding
    • Giacomo raises example of McDonald's logo, which is yellow that does not contrast sufficiently on white, though it is sometimes complemented by a darker gray circle, but the logo itself is arguably still low-contrast. This would fail now?
      • Patrick: Yes, you'd need something around it to ensure the UI component contrasts. The logo itself would be exempted, the UIC isn't
      • Gundula: Even if it's not clearly visible due to poor contrast, you can tell that something is there even if you can't perceive exactly what it is
        • Patrick: I would accept that, still better than today's argument that as soon as it's a logo I can completely ignore it
    • Giacomo: Another argument is that we have the exception that it's OK as long as it's also placed somewhere else in the page, but arguing that a footer link exempts one of the first things in the header of the page is arguably a false equivalence - the footer serves a completely different purpose, has a different behavior, seems like it shouldn't count as an exemption
      • Patrick: Still slightly better than the blanket "we don't care" of today. This was done as a softening/concession
    • Ken: Is it really appropriate to define more granular exemptions only in informative as "best practice"? Does this have no teeth without being in normative text?
      • Patrick: If you read only the normative text, the hard line is there are no ways to mitigate. This surfaces the notion of having an accessible alternative.
    • Bruce: I didn't find dismissing this very compelling, so I'm all for revisiting.
    • Giacomo: Initially joked about user interface component definition, but that definition does mention "perceived by users as a single control for a distinct function", i.e. it needs to be distinguishable as a control
    • Gundula: The logo may be hard to discover for keyboard or screen reader users if focus starts later in the page
    • Giacomo: If you delete all styles, image links are not marked visibly by the user agent in any way
      • Patrick: Curious about the history of this, whether it's a recent change to browsers
    • Patrick proposes moving to Ready for approval to get AGWG to weigh in further, not necessarily expecting unanimous approval
      • Ken notes we should maybe call this out to clarify its disposition when we send the next email
  • #4824: Focus obscured and semi-transparent/blurred overlays - reword, and DO make it fail at AAA
    • Giacomo: wondering if this should also encompass 2.4.3, or maybe in a subsequent PR
    • Ken: I might be asking the same thing, but if focus is on something outside of a popover with an overlay, that seems like a bigger issue, but I guess this also covers interfaces that pop over e.g. due to scroll position
    • Moved to Ready for approval
  • #5060: Remove the swipe example from G219, tweak wording of example single pointer non-drag gestures
    • Clarifies that the final sentence is a list of examples, removes an example that substitutes one problem for another, and simplifies punctuation/grammar
    • Moved to Ready for approval
  • #5122: Convert to in Understanding 1.4.11 example SVGs
    • Came out of a discussion on #4960
      • Patrick had previously encouraged and practiced converting text to paths, but that hadn't been done initially on the 1.4.11 SVGs Adam created; this rectifies that
      • Ken had initially had some pushback on this idea, but then realized that some of the SVG text in #4960 ended up causing misalignment within the parent button, or relative to a focus rectangle or underline, etc., so ultimately also agreed to this correction
    • Agreed as bugfix as this should be (nearly) visually identical
    • Moved to Fully reviewed (to be merged at the time of the next email and mentioned therein)

Clone this wiki locally