Re: [EXT] Re: Visible controls - Design canvas exception

+1 to Sarah’s suggestion. Seems like sound thinking.

From: Sarah Horton <sarah.horton@gmail.com>
Date: Tuesday, April 12, 2022 at 4:22 AM
To: Michael Gower <michael.gower@ca.ibm.com>
Cc: Alastair Campbell <acampbell@nomensa.com>, WCAG list <w3c-wai-gl@w3.org>
Subject: [EXT] Re: Visible controls - Design canvas exception
Resent-From: <w3c-wai-gl@w3.org>
Resent-Date: Tuesday, April 12, 2022 at 4:21 AM

Thanks, Mike.

What if the approach was something like:


  1.  Assess: What things on this page are interactive?
  2.  Refine: Requires that the use of hover or focus not be the only way of indicating the thing is interactive.

The first step seems doable and the second step is similar to color, where for each interactive thing I make, I need to provide another indicator of interactivity. Like color, that indicator could be many things and will be harder to assess, but from a design and implementation perspective (which is more important than an assessment, getting it right in the first place!) the guidance is clear and the process is manageable.

Best,
Sarah


On Apr 11, 2022, at 3:57 PM, Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote:

I think focusing on the difference between Use of Color and Visible Controls is a useful exercise.

Use of Color:

  1.  starts from something fairly easy to get agreement on (and detect with tools) -- What things on this page use chromatic colors?


  1.  Requires that that use of chromatic color not be the ONLY way of  achieving 4 criteria.

Those 4 criteria are not easy things to assess, but these two starting points make it quite a refined process. There’s also a technique that makes it a easier to align different assessors’ perspectives --  display the page in gray tone (i.e., strip out all the chromatic color).

Now, let’s look at Visible Controls. In my opinion, the approach tried is similar (start with an initial factor to assess, then refine it), but the concept is much harder to refine. It requires:

  1.  that a control isn’t visible until hover or focus makes it visible
  2.  that a visual indicator of the component is available

The first step is pretty clear, although MUCH more laborious and therefore expensive to assess (and more difficult to test with tools). But it’s the second step where this really becomes problematic. How do you get agreement on what constitutes a visual indicator? The responses from the last survey make it clear we are nowhere near achieving something people can use to arrive at similar assessments.

You said:

  *   I believe our job is to keep exploring ways to make it work!
I agree. However, we have run out of time with 2.2, so as with anything that hasn’t shaken out despite a lot of work, it needs to move on to the next version.

Mike

From: Sarah Horton <sarah.horton@gmail.com<mailto:sarah.horton@gmail.com>>
Date: Monday, April 11, 2022 at 3:23 AM
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, WCAG list <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: [EXTERNAL] Re: Visible controls - Design canvas exception
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd


Hi, Alastair.

Other SCs require judgement, like SC 1.4.1 Use of Color. First you have to identify instances where you use color to convey information, indicate an action, prompt a response, or distinguish a visual element, and then you have to convey, indicate, prompt, or distinguish that element using another visual means, which may be contextual, like a list of links, or it might be visual, like an underline or outline, or it may be text, like a label or instruction. What serves as an effective visual means changes. Conventions come and go. People understand things differently. But still, the SC guides designers to pay attention to how they use color and avoid making choices that result in people not having access to information.

Similarly, with 3.2.7 Visible Controls, whenever you provide interactive element you have to provide visible information about its interactivity, through context, a visual indicator, text, etc.

I agree that any SC that ends up requiring a catalogue of examples is problematic. 2.4.11 Focus Appearance (Minimum) currently has 19 figures. When that happens it seems like an indicator that we probably need to go back to the drawing board, revisit the intent of the SC, and try out another approach.

And I agree that it’s complicated, but I’m not ready to say, “I don’t see how it would work.” I believe our job is to keep exploring ways to make it work!

Best,
Sarah




On Apr 6, 2022, at 12:46 PM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:

Hi Sarah,

> Making actionable elements recognizable to users is the essence of user interface design.

Ok, but how do we define that in a consistent way? The only way I can think of would be with a catalogue of examples.


> We can provide guidance that will help make actionable elements recognizable to all users.

Guidance I agree with, and there is some in coga-usable<https://www.w3.org/TR/coga-usable/#clearly-identify-controls-and-their-use-pattern>, but that isn’t the same as a testable SC in WCAG 2.x.

Sidenote: I am also sceptical that we could provide guidance that would work for all users for all scenarios because of the reliance on conventions & expectations.
I.e. If the vast majority of users understand what is actionable by context (e.g. media controls, or objects in a design canvas) there would be a lot of resistance to adding something that would (for most people) get in the way.


> The task was not clearly defined as to what we were looking for in the examples

I think one or two people defaulted to “does it pass the whole SC”, but just from the conversation in the call we could hear that people had different assumptions about what would be a visible indicator.

In the current SC a visible indicator is our benchmark of whether something is recognizable as actionable. The visible indicator could be the element itself, or a separate thing.

The github/teams avatars is a useful example as they split opinions down the middle. To me there is nothing inherent in the design of the avatars that indicates you get more controls on-hover (or the bold text next to them). I only know they are actionable because it keeps popping-up (annoyingly) as I mouse around. It has changed my expectations.
However, that creates a site-convention, not a universal one.

When you get down to it, blue links are a convention. A fairly universal one, but I do remember doing usability testing in the early 2000s when we’d still find people who didn’t understand that.

Without a list of approved (and internationalised?) conventions, or an alternative approach to testing (in WCAG 3), I don’t see how it would work.

-Alastair