Contrast minimum: Address the active (pressed) state

[mfairchild365]

From #157: the active state (the typically split-second state when a button or control is being clicked or pressed) is not explicitly required to meet the contrast requirement.

This question comes up from time to time. The answer to this is provided in #157 but you have to dig to find it. Hopefully this change will make it easier to find the answer.

[netlify[bot]]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	71fba36046cb5fa300b81c23deef1166e665b4a9
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/6724d5b9392edd0008d026ff
😎 Deploy Preview	https://deploy-preview-4127--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 site configuration.

[w3cbot]

mfairchild365 marked as non substantive for IPR from ash-nazg.

[patrickhlauke]

At the risk of reopening old wounds, I'm not sure the decision to somehow special-case/exempt "temporary" states isn't a slippery slope. And frankly I'm not sure why you'd want to have low-contrast active states to begin with. Might be worth bringing this up for discussion again, as I'm really not sure there's a defensible rationale (other than "back in 2014 the group said it's ok, so we'll honour that decision")

[stevefaulkner]

(other than "back in 2014 the group said it's ok, so we'll honour that decision")

not a good enough reason

[GreggVan]

What is the rationale for requiring the contrast to pass during the feedback that a button has been pressed.

It makes sense for it to maintain contrast for hover or focus. And I can see a slight advantage to having it maintain focus while depressed with a mouse (you can still slide off it and not click it to cancel). But that is pretty borderline, does not exist for a keyboard activation But I would think it was more important to have good change in contrast between focus and activated state for feedback.

I don’t think that it is an accessibility problem if the contrast drops during the moment of activation. The person has all the time in the world to view and read the text on the button before they activate it. So it is accessible.

Gregg

On Nov 1, 2024, at 8:20 AM, Steve Faulkner @.***> wrote:

(other than "back in 2014 the group said it's ok, so we'll honour that decision")

not a good enough reason

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/pull/4127#issuecomment-2452055938, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXTN357D2SVG2UHNCEDZ6OL2XAVCNFSM6AAAAABRAIHZUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJSGA2TKOJTHA. You are receiving this because you are subscribed to this thread.

[patrickhlauke]

what is the need for the exemption? what is this trying to solve/allow? what sites would unnecessarily fail without this strangely specific exemption?

[mfairchild365]

I’m all for opening old wounds! 🤣

Honestly, I just created this pull request because in the linked issue it sounded like a settled question. Personally, I think it should fail normatively, but with a minimal impact / severity (of which WCAG has no concept of).

Im totally fine if we want to discuss this further rather than merge.

[patrickhlauke]

If the idea is that contrast ratios don't apply to things in general that happen very quickly/for a short period of time - like a quick transition for instance - then it's worth defining this in broad terms, rather than just mentioning the ultra-specific case of :active state of something.

[mfairchild365]

I don’t think this should apply to things in general that happen very quickly. Sometimes important information will flash on the screen (which may fail a different SC), but that content should still have sufficient contrast.

I think the argument here is that the element itself is not transitory. Instead it’s just a state that is transitory and attached to a permanent element that contains the same text / information that displays in the transitory state. Additionally, the state is triggered by the user and is displayed for only a brief moment before the element is removed. It’s only the moment in time when an element is being activated.

Again, normatively, I think this should fail. Should I update the PR to clarify that it fails?

[mraccess77]

It seems like updating the documentation on active state may require some sort of review by the wider group.

[patrickhlauke]

In the first instance, we'll discuss it in the WCAG 2.x backlog meeting/subgroup, to then take it to the wider AGWG