Re: Pre CFC - Hidden Controls

Hello Wilco,

I'm responding to your points in below, slightly out of order.

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

This is correct. The primary purpose of this SC is to help users with
cognitive and learning disabilities more easily find controls by ensuring
they are visible.  It is addressing an increasingly common design pattern
where controls are invisible until the user hovers over them with the mouse
or moves the keyboard focus to them.

*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 ..."?  *

If I understand correctly, you are suggesting we change:

Controls needed to progress or complete a process are visible at the time
they are needed without requiring pointer hover or keyboard focus, or a
mechanism is available to make them persistently visible.


to

Controls needed to progress or complete a process can be made visible at
the time they are needed without requiring pointer hover or keyboard focus,
or a mechanism is available to make them persistently visible.


The purpose of this SC is to stop someone from having to hunt for a
control. I believe the proposed rewording shifts the focus from being
visible to being able to be made visible. This is a subtle difference but I
think it is a big change away from the original intent.


*If menus open only on click, that seems to pass, but if a menu opens on
hover / focus alone, that seems to fail. *

If the top level of the menu is visible, a hamburger menu is available, or
another icon indicates the menu it would pass regardless of how it was
expanded.


*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?*

Can you send an example of this that passes 2.1.1?  This is the example
that I am aware of:
https://examples.sencha.com/extjs/5.1.0/examples/kitchensink/#cell-editing
and it would fail 2.1.1.  From what I've seen, when something is coded to
pass 2.1.1 then keyboard focus portion of this SC would apply. Also, if the
text could be edited elsewhere in the process, then it would pass.


Kind regards,

Rachael


On Tue, Jun 16, 2020 at 7:13 AM Wilco Fiers <wilco.fiers@deque.com> wrote:

> 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> 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
>>
>> "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
>
>

-- 
Rachael Montgomery, PhD
Director, Accessible Community
rachael@accessiblecommunity.org

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