Re: Visible controls

So far I think the wording we have can go for public review.

Regarding Wilco's comment, about the cyclic definition about a UIC being
"something perceived by users", and the SC referencing that term f(UIC) or
something that is not visible at some point in time and is visible at
another point based on the hover. I understand that rational, but I don't
think I would look at the definition of the UIC on a timeline like that...
I think I would rather look at the UIC as something that is part of the web
page and is rendered as part of the page (when the user hovers).  I think
we are fairly clear in the understanding. Will be interested in what the
outside stakeholders think. I've never heard anyone say "a modal dialog is
not a UIC because sometimes it's not visible."

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>


On Thu, Jan 28, 2021 at 1:00 PM Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> I agree with Sarah’s description of the issue. I’ve also noticed that
> Confluence has a feature that when you select text a comment option
> appears.  I wasn’t able to find the feature any other way other than just
> happening to select text.
>
>
>
> Jonathan
>
>
>
> *From:* Sarah Horton <sarah.horton@gmail.com>
> *Sent:* Thursday, January 28, 2021 10:58 AM
> *To:* Wilco Fiers <wilco.fiers@deque.com>; Alastair Campbell <
> acampbell@nomensa.com>
> *Cc:* WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject:* Re: Visible controls
>
>
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> 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>
> 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>
>
>
>