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