Re: WCAG 2.2 status - Visual indicators

> *Not working instance: *Where someone who knows quite a lot about
accessibility has hidden the actual control (e.g. a button) behind a styled
control, the CSS won’t have any effect. For example, you have a fancy
toggle button (including focus indicator), but the actual button is hidden
behind that display. In that case the CSS won’t show anything because it is
acting on the hidden control, not the visible one. This approach would not fail
the wording of the SC as it is a ‘does not break things’ approach, but from
a user point of view you’d have odd gaps. A quick visual example:
https://alastairc.uk/tmp/buttons-hidden.mp4
<https://urldefense.proofpoint.com/v2/url?u=https-3A__alastairc.uk_tmp_buttons-2Dhidden.mp4&d=DwMGaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=aVLn1jQbJkAO2FOZO49rjXOQ2rjyH0s9mOZavVhXngw&s=fP_egypzilzuybE1s0a8FNaQG5mDPlJ84CrSQaXdvrw&e=>
  (tabbing through the interface, and then turning on the visual indicators
CSS).

David M Response

Yes I understand... this does require some thought. Usually in those cases
there is a span/div/anchor/listitem/textarea  with a role, tabindex=0 and
JS to pass values ... the value entered by the user is passed to the hidden
component. So this would make it even more important to provide
proper roles (i.e., role=button) and tabindex="0" on the elements that are
visually representing the component.  We could add some language that
ensures that the component *can be* manipulated.

In content implemented using markup languages that support visual
adaptation of user interface components
<https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> with style
properties <https://www.w3.org/TR/WCAG21/#dfn-style-properties>,  the
following affordances can be adjusted with no loss of content or
functionality, and by changing no other style property:

   -

   Button and input borders; up to 3px (CSS) in width
   -

   Link underlines; up to 2px (CSS) in width

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  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, Jan 14, 2020 at 12:40 PM Hall, Charles (DET-MRM) <
Charles.Hall@mrm-mccann.com> wrote:

> Thanks. I am so glad you caught that. Apologies for the confusion from
> jumping threads.
>
> All of my emails to the list since Saturday have been on the Icon
> Description SC.
>
>
>
> Since affordance was a key concern in my comments on that SC, I missed the
> cue that this was not the same thread.
>
>
>
> *Charles Hall* // Senior UX Architect
>
> Invited Expert, W3C Accessibility Guidelines Working Group
>
>
>
> (he//him)
>
> charles.hall@mrm-mccann.com
>
> W +1.248.203.8723
>
> M +1.248.225.8179
>
> 360 W Maple, Birmingham MI 48009
>
> mrm-mccann.com <https://www.mrm-mccann.com/>
>
>
>
> [image: MRM//McCann]
>
> Cannes Network of the Year
>
> Effie’s Most Creatively Effective Global Network 2018, 2019
>
> Adweek 2019 Global Agency of the Year
>
> IPG Agency Inclusion Vanguard – Agency of the Year 2019
>
>
>
>
>
> *From: *Alastair Campbell <acampbell@nomensa.com>
> *Date: *Tuesday, January 14, 2020 at 11:12 AM
> *To: *"Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>
> *Cc: *WCAG list <w3c-wai-gl@w3.org>
> *Subject: *[EXTERNAL] Re: WCAG 2.2 status - Visual indicators
>
>
>
> Hi Charles,
>
>
>
> Sorry, I think there’s a bit of confusion, we have two going at the
> moment:  Visual Indicators is the affordances-oriented one, and Icon
> Descriptions is a separate SC.
>
>
>
> I was commented on the former, you were commenting on the latter!
>
>
>
> My comment was to do with having visual indicators, where a proposed
> (fallback) solution was for users to run a plugin that would automatically
> highlight the controls.
>
>
>
> Having run that plugin for a week, this alternative assumption about
> finding interactions was very obvious to me!
>
>
>
> Sorry, it’s a bit of a tangent as it wasn’t really a preferred option
> anyway.
>
>
>
> -Alastair
>
>
>
>
>
> *From: *"Hall, Charles (DET-MRM)"
>
>
>
> RE: “Finding a control is based on the desire to achieve something, not
> the recognition of what is interactive.”
>
> & “The process is:
>
>    - I want to do something (e.g. message someone in IRC, rate a product
>    etc.)
>    - I scan the interface for that thing.
>    - I click/select the first thing that might achieve that.”
>
>
>
> Also true: Finding a control is based on the desire to understand what is
> possible, not the completion of a pre-considered task.
>
> The process is:
>
>    - I followed a link and ended up here
>    - I scan the interface for what is possible
>    - I tap/click/select the thing that matches my interest and clearly
>    indicates I can
>
>
>
> I don’t think the SC needs to make assumptions on user intent. It simply
> needs to solve the problem – understanding what the icon means. The
> proposed AA / AAA wording is much closer to something I could support, but
> would still prefer to see techniques for the mechanism where hover, focus,
> click or keypress are also understood (have clear affordance).
>
>
>
>
>
> *Charles Hall* // Senior UX Architect
>
> Invited Expert, W3C Accessibility Guidelines Working Group
>
>
>
> (he//him)
>
> charles.hall@mrm-mccann.com
>
> W +1.248.203.8723
>
> M +1.248.225.8179
>
> 360 W Maple, Birmingham MI 48009
>
> mrm-mccann.com <https://www.mrm-mccann.com/>
>
>
>
> [image: MRM//McCann]
>
> Cannes Network of the Year
>
> Effie’s Most Creatively Effective Global Network 2018, 2019
>
> Adweek 2019 Global Agency of the Year
>
> IPG Agency Inclusion Vanguard – Agency of the Year 2019
>
>
>
>
>
> *From: *Alastair Campbell <acampbell@nomensa.com>
> *Date: *Tuesday, January 14, 2020 at 10:32 AM
> *To: *WCAG list <w3c-wai-gl@w3.org>
> *Cc: *David MacDonald <david100@sympatico.ca>
> *Subject: *[EXTERNAL] Re: WCAG 2.2 status - Visual indicators
> *Resent-From: *<w3c-wai-gl@w3.org>
> *Resent-Date: *Tuesday, January 14, 2020 at 10:31 AM
>
>
>
> Hi everyone,
>
>
>
> Just to follow-up with an observation about the alternative wording
> version. (The one which requires it doesn’t break when you apply certain
> styling to highlight controls).
>
>
>
> The CSS David suggested works fairly well on most sites, I’ve added a
> couple of things [1] to capture more controls, but generally it works.
>
>
>
> *Not working instance:*
>
> Where someone who knows quite a lot about accessibility has hidden the
> actual control (e.g. a button) behind a styled control, the CSS won’t have
> any effect.
>
>
>
> For example, you have a fancy toggle button (including focus indicator),
> but the actual button is hidden behind that display. In that case the CSS
> won’t show anything because it is acting on the hidden control, not the
> visible one.
>
>
>
> This approach would not fail the wording of the SC as it is a ‘does not
> break things’ approach, but from a user point of view you’d have odd gaps.
>
>
>
> A quick visual example: https://alastairc.uk/tmp/buttons-hidden.mp4
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__alastairc.uk_tmp_buttons-2Dhidden.mp4&d=DwMGaQ&c=Ftw_YSVcGmqQBvrGwAZugGylNRkk-uER0-5bY94tjsc&r=FbsK8fvOGBHiAasJukQr6i2dv-WpJzmR-w48cl75l3c&m=aVLn1jQbJkAO2FOZO49rjXOQ2rjyH0s9mOZavVhXngw&s=fP_egypzilzuybE1s0a8FNaQG5mDPlJ84CrSQaXdvrw&e=>
>  (tabbing through the interface, and then turning on the visual indicators
> CSS).
>
>
>
> *Where affordances matter:*
>
> Browsing with the CSS on, there are some interfaces where it is completely
> overwhelming. IRC Cloud is an example, around 50% of the interface is a
> link or control.
>
>
>
> It occurs to me there is assumption that we need to understand and include
> somehow:
>
>    - Finding a control is based on the desire to achieve something, not
>    the recognition of what is interactive.
>
>
>
> For example, in the IRC cloud client everyone’s name is a button. That
> button is integrated into the content. Does it matter that you can’t tell
> it is interactive? If you want to message someone, click on their name. the
> design to do something comes first, then the interface allows it in every
> way possible.
>
>
>
> The process is:
>
>    - I want to do something (e.g. message someone in IRC, rate a product
>    etc.)
>    - I scan the interface for that thing.
>    - I click/select the first thing that might achieve that.
>
>
>
> I’m not saying it is a good or bad thing, but it is a very different
> assumption about how interfaces should work.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> *1]* My current CSS for Stylus:
>
> button, [role="button"], input[type=submit], [role="listbox"],
> [role="tab"] {
>     box-shadow: inset 0 0 0 2px #036, 0 0 3px 1px yellow !important;
>     outline: white !important;
> }
>
> a:link, [role="link"] {
>     text-decoration: underline;
> }
>
> This message contains information which may be confidential and
> privileged. Unless you are the intended recipient (or authorized to receive
> this message for the intended recipient), you may not use, copy,
> disseminate or disclose to anyone the message or any information contained
> in the message. If you have received the message in error, please advise
> the sender by reply e-mail, and delete the message. Thank you very much.
>