Re: Visible controls

Hey Alastair,

> “Where receiving pointer hover or keyboard focus triggers user interface
components to be visible, information needed to identify that user
interface components are available is visible, except when:”

Yes, this looks better I think. Thank you.



On Fri, Jan 29, 2021 at 3:34 PM Alastair Campbell <acampbell@nomensa.com>
wrote:

> *> *we don't apply 4.1.2 until the modal is actually rendered.
>
> 4.1.2 applies when it is visible, and it applies when it is not visible.
> We trigger the different states in order to test 4.1.2 across all those
> states.
>
>
> > By definition it is not possible for a component to be a UIC in a state
> where it isn't perceivable.
>
> If that is the logic, then starting the SC with:
> “For user interface components that appear on pointer hover or focus”
> does not help, because it contradicts itself.
>
> > It's like saying you are driving a parked car. Whatever the rules are
> while you're driving, they do not apply when the car is parked.
>
> In the UK you can be prosecuted for drink driving whilst in a parked car,
> or even whilst not in your car if you have the keys. But I digress…
>
> I still think that SCs apply across states, including 4.1.2 and this new
> one, and the SC scope is about having a visual indicator in advance of the
> state change.
>
> If we re-formulated to something like 1.4.13 I think it would be:
>
> “Where receiving pointer hover or keyboard focus triggers user interface
> components to be visible, information needed to identify that user
> interface components are available is visible, except when:”
>
> Is that better?
>
> -Alastair
>


-- 
*Wilco Fiers*
Axe-core product owner - Co-facilitator WCAG-ACT - Chair ACT-R


Join me at axe-con <http://deque.com/axe-con> 2021: a free digital
accessibility conference.

Received on Tuesday, 2 February 2021 11:13:38 UTC