RE: Pre CFC - Hidden Controls

Hi Wilco, an example of this issue was in Slack when you had to focus a particular bit of text for a related “edit” or “settings” button to appear.  If you don’t hover or focus the text you would never know that an edit or settings button would be available as the text doesn’t look editable and I recall the edit or settings functions opened a dialog.  So it’s less about the element opening on focus or hover but the presence of the option.  I’d say a menu button that open’s on focus/hover or click/enter could pass as the menu button itself is always present.   But it’s a careful distinction we need to cover.

Jonathan

From: Wilco Fiers <wilco.fiers@deque.com>
Sent: Tuesday, June 16, 2020 7:14 AM
To: Rachael Bradley Montgomery <rachael@accessiblecommunity.org>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Pre CFC - Hidden 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.

Hey Rachael,
Thanks for reaching out. I'm having a hard time wrapping my head around this SC. Perhaps just some clarifications would be helpful. The main thing I'm struggling with is the relationship between "visible" and "without requiring pointer hover". It seems to me the way this is written up is that if something is ever invisible, it fails the SC. Whereas what I think the intent was is that it must be possible to make it visible without hover or focus, right? So should "controls ... are visible without" be changed to "controls ... can be made visible without ..."?

The second thing that stands out to me is about menus. If menus open only on click, that seems to pass, but if a menu opens on hover / focus alone, that seems to fail. For example the "Schedule send" button in GMail opens when you click the little arrow on the "send" button. If instead of opening on click, that opened on focus / hover, it sounds like that difference should cause it to fail the SC. That doesn't seem like the type of "hover" that should fail the SC.

It strikes me that "hover or focus" may be a symptom of what this SC is trying to address, and not the actual problem. The problem seems to be that users shouldn't have to go hunt around the page to find what they need, that what they need should be readily available. Does it really matter if how they expose the controls they need are exposed through hover instead of click / touch? I would argue touch is worse. If I have to click a text before it's made apparent that it's editable, isn't that even worse than if that became clear from when I hovered it? Why does that get a pass?

My suggestion would be to continue to work on this.

W







On Thu, Jun 11, 2020 at 2:26 AM Rachael Bradley Montgomery <rachael@accessiblecommunity.org<mailto:rachael@accessiblecommunity.org>> wrote:

Hello,



On a previous call ( https://www.w3.org/2020/02/11-ag-minutes.html#resolution01) we had resolved that Hidden Controls was almost ready but needed a technique. That is complete and the Pull Request in github shows the new SC, the understanding document, and the technique: https://github.com/w3c/wcag/pull/1127




Are there any remaining concerns before we move to CFC?



Kind regards,



Rachael

--
Rachael Montgomery, PhD
Director, Accessible Community
rachael@accessiblecommunity.org<mailto:rachael@accessiblecommunity.org>

"I will paint this day with laughter;
I will frame this night in song."
 - Og Mandino



--
Wilco Fiers
Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]