Re: WCAG 2.2 status - Visual indicators

> I’d propose a solution – the test would be similar to 1.4.12 that if you
apply your proposed code and it doesn’t change the affordance then the
author has to provide it directly or provide a mechanism for an
affordance.  That way we don’t require anything for situations where simply
applying basic CSS works – but for people who have done something special
we require them to either provide the affordance or provide a style
switcher.  This seems like a good compromise and is in line with 1.4.12 and
1.4.3.

Agree, it might also have some positive impact on the excessive use of
these fake front ends for components...

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 Thu, Jan 16, 2020 at 10:48 AM Jonathan Avila <jon.avila@levelaccess.com>
wrote:

>
>    - 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.
>
>
>
> It’s not so much that the component is hidden – it’s generally off-screen
> and the AT is seeing the off-screen element.  Applying role’s to the span
> would be problematic as then you’d have 2 elements seen by the assistive
> technology.  What we’d want to make sure then is that you can change style
> to the element and have it visually apparent – in this case if you change
> the off-screen input it is either off the edge or covered over and so other
> styling would overwrite it even if it was changed.   The user would need to
> be savvy enough to edit a custom CSS or turn CSS off completely to cover up
> the overlay element – this is likely too complex for most users and
> specific to the implementation.  Turning off CSS completely is counter to
> this.    I don’t think your recommendation would solve this issue when the
> control is not display none but simply obfuscated.
>
>
>
> I’d propose a solution – the test would be similar to 1.4.12 that if you
> apply your proposed code and it doesn’t change the affordance then the
> author has to provide it directly or provide a mechanism for an
> affordance.  That way we don’t require anything for situations where simply
> applying basic CSS works – but for people who have done something special
> we require them to either provide the affordance or provide a style
> switcher.  This seems like a good compromise and is in line with 1.4.12 and
> 1.4.3.
>
>
>
> Jonathan
>
>
>
> *From:* David MacDonald <david100@sympatico.ca>
> *Sent:* Wednesday, January 15, 2020 2:18 PM
> *To:* Hall, Charles (DET-MRM) <Charles.Hall@mrm-mccann.com>
> *Cc:* Alastair Campbell <acampbell@nomensa.com>; WCAG list <
> w3c-wai-gl@w3.org>
> *Subject:* Re: WCAG 2.2 status - Visual indicators
>
>
>
> *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.
>
>
>
> > *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.
>
>