RE: WCAG 2.2 status - Visual indicators

  *   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



CanAdapt Solutions Inc.

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://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<mailto: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<mailto: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/>

[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<mailto:acampbell@nomensa.com>>
Date: Tuesday, January 14, 2020 at 11:12 AM
To: "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com<mailto:Charles.Hall@mrm-mccann.com>>
Cc: WCAG list <w3c-wai-gl@w3.org<mailto: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<mailto: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/>

[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<mailto:acampbell@nomensa.com>>
Date: Tuesday, January 14, 2020 at 10:32 AM
To: WCAG list <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Cc: David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>
Subject: [EXTERNAL] Re: WCAG 2.2 status - Visual indicators
Resent-From: <w3c-wai-gl@w3.org<mailto: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.