Re: Visible controls (aka hidden controls)

+1 Jon.

This is why I had originally proposed to broaden the overall scope in the
opening sentence, but leave the second, COGA specific sentence in place to
firmly put focus on the *primary* beneficiary group.  This proposed SC has
specific benefits for COGA users, but for other user-groups as well, and I
fear we lose something when we get too narrow - it's not adding clarity,
it's overly-filtered (IMHO).

JF

On Thu, Dec 10, 2020 at 3:31 PM Jonathan Avila <jon.avila@levelaccess.com>
wrote:

> I’d vote to add in users with low vision as this criteria has specific
> benefits to this group.  I’d further summise that it has benefits to other
> groups as well such as users with motor disabilities including those who
> use speech recognition software as tabbing around and hovering are likely
> things that would be more challenging for this group.
>
>
>
> Jonathan
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Thursday, December 10, 2020 1:09 PM
> *To:* John Foliot <john.foliot@deque.com>
> *Cc:* WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject:* RE: Visible controls (aka hidden controls)
>
>
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Thanks John,
>
>
>
> I’ve incorporated most of those, slightly simplified in places:
>
>
> https://github.com/w3c/wcag/pull/1559/commits/53b3b14b349f9c5af5c92047224b89b8a1945e77
>
>
>
> The two I didn’t update were:
>
>    - “*can be easily found by *people with cognitive disabilities *users **when
>    they are needed*”.
>    This SC comes from a COGA point of view, and we should be clear about
>    that. If there are additional benefits, great, but let’s keep it clear.
>    - Also: “*interactions can leave some users without a **perceivable *
> *path forward”. *This part of the intent is trying to make a point about
>    the experience, and from the users’ point of view it is “without a path
>    forward”, which (IMHO) makes the point more strongly.
>
>
>
> This will be back up for review next week.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
>
>
> *From:* John Foliot
>
>
>
> 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...)
>
>
>
>
>
>

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