RE: Visibly hidden controls

Sean said: ". . . then using the arrow keys, enter, and space-bar should 
be [utilized] like has been done for many years on standard desktop 
environments. For example: Menus . . .]

that is exactly my point, you said it better than I, sorry for any 
confusion.
When the UX designers invent new and non-desktop control, (such as the 
video with only a large play button visible, the hamburger menu, the gear 
settings menu, etc.), that is when the "# how does the user know how to 
interact with it?" has to be better thought out, designed, tested, and 
documented for keyboard and accessible gesture interactions.  The end-user 
has some responsibility in this contract too, to correctly set their 
preferences, learn new controls, and perhaps even new paradigms.  Remember 
when the community was all concerned when gestures first came out on the 
iPhones?  With the correct feedback, it was shown that a blind user could 
be just as effective and efficient as a sighted user using the gestures - 
without requiring an attached keyboard. 

The principle here I use is that the "ability to learn new accessible 
controls, has to be balanced with the efficiency in using them in an 
accessible manner - but remember you learn it once and use it over and 
over, so balance accordingly."
___________
Regards,
Phill Jenkins
pjenkins@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility
ibm.com/able
facebook.com/IBMAccessibility
twitter.com/IBMAccess
ageandability.com




From:   "Sean Murphy (seanmmur)" <seanmmur@cisco.com>
To:     Phill Jenkins/Austin/IBM@IBMUS, Terrill Thompson <tft@uw.edu>
Cc:     "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Date:   12/05/2016 07:17 PM
Subject:        RE: Visibly hidden controls



Phil,
 
In relation to your reply, I agree with the overall statement as long as 
the user environment is clean, simple to understand and the end-user 
regardless who they are, do not have to guess what to do within an 
application. The following point from your post, I have a slightly 
different view and only applies in certain situations:
 
?I even recommend not to have the tab stop at all and every control, but 
to have them grouped and allow the arrow keys to move among and between 
the controls, while the tab key only stops at the player.  We want more 
efficient keyboard behavior too don't we?    There is no success criteria 
that says the tab key has to stop at each and every controls.  But to keep 
the keyboard interaction simple, tab and arrow keys usually suffice, even 
in the mobile app paradigm.?
 
The tab stop places someone on a element (control) that they need to 
interact with. If the control contains other children controls, then using 
the arrow keys, enter, and spacebar should be utilise like has been done 
for many years on standard desktop environments. For example: Menus, 
Toolbars, Tab Strips, etc. thus when the focus lands on a menu and the 
user presses tab. The focus moves to the next control, not within the 
menu. 
 
In relation to a media control. If they are using a toolbar, then what you 
stated above applies. If a dialog appears, then standard tab navigation 
applies. It all depends on how they impleament the cleaner UX. The 
question is if they use application mode or not. As application mode not 
done correctly reduces some disabilities ability of understanding of what 
is occurring.
 
Getting back to the original question. If a key is pressed and doesn?t 
open the controls. Then 2.1.1 as already suggested I think would apply. AS 
the keyboard user cannot access the controls.
 
 
Sean Murphy
Accessibility Software engineer 
seanmmur@cisco.com
Tel: +61 2 8446 7751       Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com 
 Think before you print.
This email may contain confidential and privileged material for the sole 
use of the intended recipient. Any review, use, distribution or disclosure 
by others is strictly prohibited. If you are not the intended recipient 
(or authorized to receive for the recipient), please contact the sender by 
reply email and delete all copies of this message.
 
From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: Tuesday, 6 December 2016 11:54 AM
To: Terrill Thompson <tft@uw.edu>
Cc: w3c-wai-ig@w3.org
Subject: Re: Visibly hidden controls
 
I believe you're making a case for "learnability" vs "accessibility", 
which may cross over into the cognitive abilities. 
Once the user "learns" the newer more simple design that has fewer visible 
controls initially, he/she may appreciate and more often even prefer the 
simpler design. 
I believe it is more distracting to more users who have disabilities to 
have *all* the controls visible all the time. There is some data on that.

I even recommend not to have the tab stop at all and every control, but to 
have them grouped and allow the arrow keys to move among and between the 
controls, while the tab key only stops at the player.  We want more 
efficient keyboard behavior too don't we?    There is no success criteria 
that says the tab key has to stop at each and every controls.  But to keep 
the keyboard interaction simple, tab and arrow keys usually suffice, even 
in the mobile app paradigm.  

The "chromeless media players" as you called them, have to have at least "
a large play button that's overlaid over a poster image' to know its a 
video vs a static image.  That is a clean and very simple design. 
Because the "play button" implies (e.g. learnability of the widget) a 
discoverable set of video player controls, including captions on/off, 
expand, etc.  I do not believe there is any broad user studies that says 
there has to be all the visible player controls all the time. We don't 
require drop downs to always be dropped down, or expandable list to always 
be expanded, etc.  Again, its about learning how the widget (set of 
controls) behave with the keyboard and/or mouse.  But I understand your 
concern to make it behave as one might be use to or has learned it before. 

 
So, having said that, I would vote for a user agent preference that would 
default for player controls to be visible all the time, if that was the 
user agent user's preference. 
Perhaps this is a case where if the web content author is also providing 
the embedded user agent, they need to conform with UAAG?  Or is it a new 
WCAG 2.1 AAA Success Criteria that is applicable some of the time to some 
known audiences?

We can't say that we mandate a design for "one size fits all" without also 
having preferences to guide the software (in this case, disclosure of the 
controls) to act like each of us wants it uniquely. 
 
___________
Regards,
Phill Jenkins
IBM Research Accessibility
ibm.com/able
facebook.com/IBMAccessibility
twitter.com/IBMAccess
ageandability.com




From:        Terrill Thompson <tft@uw.edu>
To:        "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Date:        12/05/2016 05:26 PM
Subject:        Visibly hidden controls




Hi All, 

I'm trying to make a case in opposition of visibly hidden controls. Are 
there any WCAG 2.0 success criteria that controls to be visible without 
the user having to work hard to discover them? 

Chromeless media players are a common example. By default there are no 
controls other than (perhaps) a large play button that's overlaid over a 
poster image. When the video is playing there are no controls at all. 
However, if a mouse user hovers over the video a control bar appears. 

Depending on how it's coded the control bar might be accessible to screen 
reader users, and might even be visibly exposed to keyboard users once it 
receives focus, but from my perspective if it's not visible, keyboard 
users won't necessarily know they can tab to it.  The same applies to 
speech-to-text users. How do they know they can say "Click mute" if the 
media player has no visible Mute button? 

Does WCAG 2.0 offer any support for my position that controls should be 
visible? I'm also willing to consider opposing arguments if anyone 
disagrees (perhaps a clean, simple interface is more or equally 
justifiable). 

Thanks, 
Terrill 

--- 
Terrill Thompson
Technology Accessibility Specialist
DO-IT, Accessible Technology Services
UW Information Technology
University of Washington
tft@uw.edu