W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2020

Re: WCAG 2.2 status - Visual indicators

From: Alastair Campbell <acampbell@nomensa.com>
Date: Tue, 14 Jan 2020 16:12:38 +0000
To: "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>
CC: WCAG list <w3c-wai-gl@w3.org>
Message-ID: <C0FB4D73-D5D7-4043-870F-35862DBE9DDB@nomensa.com>
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.


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

W +
M +
360 W Maple, Birmingham MI 48009

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.



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.

(image/jpeg attachment: image001.jpg)

Received on Tuesday, 14 January 2020 16:12:47 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:34 UTC