Re: Visible controls

Hi, Wilco and Alastair. 

The issue is when an element is perceivable, but is not identifiable or recognizable as a UIC until the information needed to identify the element as a UIC become visible as the result of pointer hover or keyboard focus. 

For example, a heading that is perceivable and identifiable as a heading element, but turns out also to be a UIC. The additional information needed to identify the element as a UIC, e.g., a pencil icon or an outline or underline, displays only on pointer hover or keyboard focus.

Hope this helps!

Best,
Sarah


> On Jan 28, 2021, at 1:41 PM, Wilco Fiers <wilco.fiers@deque.com> wrote:
> 
> Hey Alastair,
> The issue is in the definition of user interface component (UIC). It says:
> > a part of the content that is perceived by users as a single control for a distinct function
> 
> By definition, something can not be a UIC until it is perceivable in some way. Taken literally, this SC is self-defeating. In a page state where the control is not perceivable, the information does not need to be visible, because the control isn't (yet) a UIC. Arguably something that isn't visible shouldn't be classified as a control either. You can't pass 1.4.1 Audio Control with a control that nobody can perceive.
> 
> I agree with you that the phrasing of it needs work, but in my opinion this SC needs to be explicit about it only applying to controls that can be revealed through hover or focus.
> 
> 
> 
> On Thu, Jan 28, 2021 at 1:51 PM Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
> > For user interface components that appear on pointer hover or focus, information needed to identify that user interface components is visible without requiring pointer hover or keyboard focus, except when:
> 
>  
> 
> I find that confusing, it appears to say “for these things which are not visible unless you hover/focus, make sure there is something visible without hover/focus”.
> 
>  
> 
> I know it is saying virtually the same thing, but it reads like it’s asking you to put placeholders in for each thing that appears on hover/focus. I’m not sure it covers the scenario where one ‘edit’ indicator reveals multiple controls on hover.
> 
>  
> 
> I’d be interested to know if other people find it more or less confusing than the current text <https://raw.githack.com/w3c/wcag/wcag22-visible-controls-update/understanding/22/visible-controls.html>?
> 
> I might be in a wood-for-the-trees situation.
> 
>  
> 
>  
> 
> > RIght, but the SC doesn't say it's only applicable to controls that show up on hover or focus. It applies to all UICs, which apparently includes components before they are even rendered.
> 
>  
> 
> I don’t follow that, what gives you the impression it is about un-rendered things? We are not writing this from a technical point of view (about whether things are in the DOM or not), although we should try not to clash with the terminology.
> 
>  
> 
> User interface components (UICs) can be present on a page (rendered?) but not visible until hover/focus, and WCAG applies whatever state the page is in. (E.g. text contrast applies no matter the state of a button.)
> 
>  
> 
> Also, it doesn’t apply to the UIC, it applies to the information indicating there is a UIC. That might be the UIC, or it might be something that shows it is there if you hover over something (one form of passing).
> 
>  
> 
> I read it as applying to the information, the indicator of a control needing to exist (with exceptions), so a basic test would be to hover over every element and see if there are controls contained in the hover-content.
> 
>  
> 
> -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.
> <deque_logo_180p.gif>