-
Notifications
You must be signed in to change notification settings - Fork 233
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
Draft SC "States Discernable" #686
Comments
as this SC is mainly "visual", i wonder if it's best not to start talking about "programmatic states", which are a 4.1.2 issue. otherwise, this may open weird scenarios. for instance, what if a control lacks programmatic states? it would fail 4.1.2, but then would pass this if it had no distinction, since nominally lacking a programmatic state it would "correspond" in that sense? Would we lose anything if we just left that part out altogether? is the concern that a control would get "out of sync" with reality? if so, maybe avoid "programmatic states" and perhaps move more towards "and accurately represent the current state of the component" or similar? is saying "are visually distinct" clear enough for normative language? i'm all for it, but can foresee similar issues as the "visible" focus indication. |
@patrickhlauke good point about unintended interactions. I think the formulation you propose ("accurately represents the current state of the component") has benefits. |
If states have to be discernible, that would arguably include the default state, which might cover the vexed issue of the invisible input discussed in #680 ? |
if a control doesn't have "states" as such (i.e. a button that just fires an interaction, and not a toggle that gets turned on/off), it would feel odd to say that its default (and only) state falls under this SC as well though, i'd say. |
Well, interactive controls would at least usually have a focused state which would make the unfocused state the default, but admittedly that would fall under the separate SC 2.4.7. Beyond that, for something to be perceived as interactive control at all, it will usually have something that sets it apart from the context (position, shape, color, underline whatever) which communicates an affordance and implies a state ("I am in rest state but interactive"). Would a way forward be to widen an SC to something like "Interface components visible and their states discernible"? I kind of dread the proliferation of so many bitty SCs that interact in multiple ways (like 2.4.7 and 1.4.11 now do). |
That may work for me, and yes agree that we're in danger of making lots of micro-SCs now in some kind of goldrush for 2.2. I'd rather see a few chunky, well thought-out SCs come out of this. |
Just taking this off the WCAG 2.2 slate, needs more research/work... |
Draft SC text for "States Discernable":
A typical example is a disclosure section where upon activation the section is disclosed and the [+] symbol turns into a [-] symbol (and
aria-expanded
is set to true).We talked about this in the mobile a11y TF - we found it hard to specify what a discernable state change is. Is changing one pixel in a graphic enough?
The formulation chosen (which I had offered to put here as draft) tries to avoid the problem of saying what exactly needs to be in place to make a state change discernable. It just says there must be some visual difference between states AND what is visible must correspond to programmatically determinable states.
For usability reasons one can assume that the state distinction is usually noticable in principle; 1.4.11 would take care that the salient part of each state has 3:1 contrast or better. The added value here is insisting on a correspondence between visual states and programmatic states, i.e. that the state change is not missing (no visual state change), not the wrong way round, and not messed up in other ways.
Not sure whether we have a clear argument that this has a higher impact on people with disabilities - LV people will have less context, cognitively impaired people may get confused more than others, etc.
The text was updated successfully, but these errors were encountered: