Re: Visible controls (aka hidden controls)

Johnny come lately...

Hi Alastair, group,

As I review this, I am struck by how many times we hammer folks over the
head with 'cognitive' in the Intent statement. While I appreciate that for
this user-group, this requirement is indeed critical*, visibly persistent
controls also can benefit Low Vision users, supports interfaces and
form-factors where "mousing over" cannot be reasonably achieved, etc.

Might I propose the following editorial edits:

*Intent of Visible Controls*

*The intent of this Success Criterion is to ensure that controls needed to
progress or complete a process can be easily found by *people with
cognitive disabilities *users** when they are needed.*

*People with low executive function, impaired memory, and other cognitive
and learning disabilities may not be able to find controls needed to
progress if they are hidden until focus is placed on them or a pointer
hovers over them. They may also not remember where the control is the next
time they interact with the site. **Additionally, some methods for exposing
hidden controls (i.e. mouse-over) may not be supported by all platforms or
user-agents.*

*Some design approaches hide controls needed to complete tasks and require
certain user interactions, such as mouse-over, to display these controls.
These required interactions can leave some users without a **perceivable **path
forward.*


As well, as I mentioned on Tuesday's call, the language around media player
controls is (at best) confusing:

Mutlimedia Controls (Note, the current draft has a spelling mistake: Mult
imedia)

*Controls such as video players, web chats, and carousels include controls
that are only visible on hover since they overlay the contents being
displayed. The video content itself is considered to be the "Information
needed to identify user interface components", like the top visible part of
a drop-down that shows sub-items. Some users may still struggle if media
controls are not persistently visible, so there is benefit to providing a
mechanism for people to keep the controls visible.*


   -   "Controls such as video players,..."
   [JF: Video players are not controls, they are components. Specifically,
   since HTML5, the web browser is the media 'player', where content authors
   can either furnish their own scripted and styled controls, or they can fall
   back to native controls furnished by the browser by using the @controls
   attribute
   <https://html.spec.whatwg.org/multipage/media.html#attr-media-controls> -
   this prompted the addition of one of the exceptions on Tuesday's call.

   Proposed edit: "Controls *Page components* such as video players, web
   chats, and carousels *frequently *include controls that are only visible
   on hover since they overlay the contents being displayed." - while also
   noting that "web chats" are not Multimedia content, although I agree that
   mentioning this type of component, which often acts similar to other forms
   of active media containers, is useful to the understanding. Perhaps instead
   of "Multimedia controls" we fall back slightly to a more generic "Embedded
   controls"]

   -   "The video content itself is considered to be the "Information
   needed to identify user interface components"..."
   [JF: the presence of the <video> element in a containing document may
   not, at the start, be rendering a "video" - it may in fact be displaying a
   static image supplied via the @poster attribute
   <https://html.spec.whatwg.org/multipage/media.html#attr-video-poster>.
   Additionally, while it is common to see a "triangle" (start) button
   superimposed over the video bounding region, that is but a current
   convention, and not a mandated rendering requirement in the HTML
   specification.

   Proposed edit:  "The video content *The presence of these types of
   embedded controls in a containing document* itself is considered to be
   the "Information needed to identify user interface components"..."

No hills worth dying on here, but offered as broader feedback to the group.

JF

(*Critical - Important? Useful? Necessary? Thesaurus time...)



On Wed, Dec 9, 2020 at 4:53 PM David MacDonald <david@can-adapt.com> wrote:

> Regarding the last proposed rewording
> >All functionality of the content can be operated by user interface
> components without requiring pointer hover or keyboard focus to first make
> the user interface components visible.”
>
> I think we better capture it with the current updated wording and the
> current update seems easier to understand than this one.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
> Mobile:  613.806.9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
> On Tue, Dec 8, 2020 at 7:22 PM Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>> Hi Folks,
>>
>>
>>
>> I updated the draft based on our discussion today, you can see the
>> changes:
>>
>> https://github.com/w3c/wcag/pull/1557/files
>>
>>
>>
>> And a previewed:
>>
>>
>> https://raw.githack.com/w3c/wcag/master/understanding/22/visible-controls.html
>>
>>
>>
>> I did a quick pass on updating the understanding document, but we still
>> need to add some more information about the exceptions. (E.g. the example
>> for skip links.)
>>
>>
>>
>> AndrewK had a last minute suggestion of:
>>
>> “All functionality of the content can be operated by user interface
>> components without requiring pointer hover or keyboard focus to first make
>> the user interface components visible.”
>>
>>
>>
>> But we didn’t have time to consider that sufficiently during the meeting.
>>
>>
>>
>> If anyone has any thoughts or objections to this approach, please do
>> comment here.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> -Alastair
>>
>>
>>
>> --
>>
>>
>>
>> www.nomensa.com
>> tel: +44 (0)117 929 7333 / 07970 879 653
>> follow us: @we_are_nomensa or me: @alastc
>> Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT
>>
>>
>>
>> Company number: 4214477 | UK VAT registration: GB 771727411
>>
>>
>>
>

-- 
*John Foliot* | Principal Accessibility Specialist
Deque Systems - Accessibility for Good
deque.com
"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"