Interactive Element Contrast Sufficient

The draft SC in #193 reads: when a user interface component visibly indicates its states, these states are visually distinct and correspond to the programmatic states. The wording deliberately dodges the question the mobile accessibility task force could not settle — how much visual difference counts, since changing one pixel in a graphic is technically a difference — and instead leans on 1.4.11 to handle the 3:1 contrast of the salient part. The value he claims for it is the correspondence itself: catching a state change that is missing, reversed, or otherwise out of sync.

Mixing programmatic state into a visual SC opens a loophole: a control with no programmatic state fails 4.1.2, but would nominally pass this one because there is nothing to disagree with. He proposed replacing that clause with wording along the lines of accurately represents the current state of the component, and also questioned whether visually distinct is firm enough for normative language, foreseeing the same problems as visible focus indication. detlevhfischer accepted the substitution as an improvement.

#197 starts from the observation that disabled interface elements work badly for people with low vision and suggests that, rather than only exempting them from 1.4.3, a better way might be a disabled icon; DavidMacDonald proposes at least 3:1 contrast OR an icon marking the element disabled. bkimmel seconds the problem, particularly where disabled controls are used to advertise the potential of an interaction — fill these fields in and you can submit — which he calls a huge safe harbour for things that cut against the Perceivable goal. He is not convinced an icon specifically is the answer.

He would far rather see some form of minimum contrast apply, to solve readability, than require an icon — WCAG cannot start demanding icons everywhere without dictating visual design. His preferred shape is a more general intent of indicating that something is disabled, and he flags a crossover with how user agents themselves render disabled state.

Reviewing #197 against the current draft, adampage notes disabled elements fall outside the definition of interactive element — an element that responds to user input and has a distinct programmatically determinable name — so the neighbouring Interactive elements distinguishable provision does not reach them. They appear instead to match non-interactive element (does not respond to user input and does not include sub-parts), but are absent from that definition's examples and notes, so the intent is unclear. He suggests broadening the term or introducing a new one for elements that exist to be interactive even when conditionally disabled or read-only, and points at the Disabled controls explained provision and w3c/wcag#5053 as related.

#207 proposes reorganising all the colour and contrast outcomes on vision-science lines: luminance carries high spatial frequency information and is what reading depends on, hue matters for object recognition and colour-coded non-text material, and spatial frequency — font weight, size, letter and line spacing, padding, glyph design — is the critical factor in readability. That yields two guidelines, one for not relying on colour alone plus non-text contrast, one for luminance contrast in readable content, with non-text use cases classified as Semantic, Symbolic, DataViz and Container. He also argues specific legacy numbers are unsupported: the 80-characters-per-line figure traces to IBM equipment economics rather than research (Bringhurst's 66 characters, or a 50 to 70 range, offered as informative), and a 1.5 line-height rule is near meaningless in CSS because the x-height to font-size ratio varies by 50 percent or more between families.