Re: Visible controls (aka hidden controls)

Erm...

s/visibly persistent controls also/easily discoverable controls


Sorry 'bout that.

JF

On Wed, Dec 9, 2020 at 6:17 PM John Foliot <john.foliot@deque.com> wrote:

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

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