Skip to content
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

Open
detlevhfischer opened this issue Apr 5, 2019 · 7 comments
Open

Draft SC "States Discernable" #686

detlevhfischer opened this issue Apr 5, 2019 · 7 comments

Comments

@detlevhfischer
Copy link
Contributor

Draft SC text for "States Discernable":

When a user interface component visibly indicates its states, these states are visually distinct and correspond to the programmatic states.

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.

@patrickhlauke
Copy link
Member

and correspond to the programmatic states

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.

@detlevhfischer
Copy link
Contributor Author

@patrickhlauke good point about unintended interactions. I think the formulation you propose ("accurately represents the current state of the component") has benefits.

@detlevhfischer
Copy link
Contributor Author

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 ?

@patrickhlauke
Copy link
Member

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.

@detlevhfischer
Copy link
Contributor Author

detlevhfischer commented Apr 13, 2019

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

@patrickhlauke
Copy link
Member

Would a way forward be to widen it to something like "interface components visible and their states discernible"?

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.

@alastc alastc added this to To do in WCAG 2.2 Jan 6, 2020
@alastc alastc added WCAG.next and removed WCAG 2.2 labels Jul 7, 2020
@alastc alastc removed this from To do in WCAG 2.2 Jul 7, 2020
@alastc
Copy link
Contributor

alastc commented Jul 7, 2020

Just taking this off the WCAG 2.2 slate, needs more research/work...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants