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<http://www.ibm.com/able>
facebook.com/IBMAccessibility<http://www.facebook.com/IBMAccessibility>
twitter.com/IBMAccess<http://twitter.com/IBMAccess>
ageandability.com




From:        Terrill Thompson <tft@uw.edu<mailto:tft@uw.edu>>
To:        "w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>" <w3c-wai-ig@w3.org<mailto: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<mailto:tft@uw.edu>