Re: Visible controls - Design canvas exception

Just to add that 1.4.1 Color is by no means restricted to interactive 
elements. It also applies to information graphics; to using colour as 
background to indicate states, say, done/not done in a table; etc.
I am pretty sure that there will be a lot of leeway in assessing whether 
there is an indication that things are interactive (as born out by the 
recent excercise). As Alastair said, it often depends on prior knowledge 
and expectations built on that, which can vary a lot.

Am 12.04.2022 um 10:20 schrieb Sarah Horton:
> 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> 
>> 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?
>>
>>  2. 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>
>> *Date:*Monday, April 11, 2022 at 3:23 AM
>> *To:*Alastair Campbell <acampbell@nomensa.com>, WCAG list 
>> <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> 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 incoga-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
>>
>

-- 
Detlev Fischer
DIAS GmbH
(Testkreis is now part of DIAS GmbH)

Mobil +49 (0)157 57 57 57 45

http://www.dias.de
Beratung, Tests und Schulungen für barrierefreie Websites