Re: WCAG 2.2 status - Visual indicators

Hi David,

            > I should mention that historically, we've been shy to assign attributes to a user.

That’s true, and I’d highlight that there is a difference between identifying something, and knowing its purpose.

The non-text contrast SC specifically points to aspects of the content and asks if they have sufficient contrast. There is some subjectivity, but it is about the content. E.g. A custom component might do radio-buttons completely differently, but there would be something you could point to that should have contrast. It doesn’t require adding/removing things, just making sure some things have contrast. (And if it doesn’t provide anything, that’s considered rubbish for everyone and not an accessibility issue as such.)

When we start talking about ‘purpose’, that goes up a level and starts requiring certain things are there (or not), and then we have to define what conveys purpose. And then we have to define what people understand for different components…

It is like a rubiks cube that we’ve twisted this way and that, but without a catalogue of examples I don’t see a way of solving it, at least from a guideline point of view.

Cheers,

-Alastair



From: David MacDonald <david100@sympatico.ca>
Date: Monday, 20 January 2020 at 15:52
To: Alastair Campbell <acampbell@nomensa.com>
Cc: "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>, WCAG list <w3c-wai-gl@w3.org>
Subject: Re: WCAG 2.2 status - Visual indicators

>...provides visual information required to understand its purpose

I should mention that historically, we've been shy to assign attributes to a user ... because what is required for one person may be different from what is required by someone else... and it leads to an untestable SC.
There may be another way to make it testable... but historically this has been our concern with SC proposals that reference the abilities of the end user.



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 Sun, Jan 19, 2020 at 5:53 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
> Is “active” stated to be more clear and direct than making an exception for inactive or disabled elements?

I think it was intended to exclude inactive components, and it could be clarified, but I think the other issues are more pressing.


Can this be described as “visible indicator” instead of “visual indicator”?
As an adjective, visual implies that the indicator is related to sight, whereas visible implies that the indicator is able to be seen.

I agree ‘visible indicator’ would equate to ‘able to be seen’, and then it would encompass any decorative elements that are part of the component.

The closest concept we have in 2.1 is “Visual information required to identify user interface components”. (Which has been particularly difficult to apply across lots of different scenarios.)

To keep it similar we could use something like:
“Each active user interface component provides visual information required to understand its purpose”

However, I suspect that there is not 100% overlap between identifying something, and understanding it’s purpose.

That leads onto the next point:

> Are there any methods, techniques and tests for “conveys its purpose”?

No, nor do we have clear guidance on what appropriate visual indicators would be per component type. See the other thread on gathering examples [1].


> Wrapping that icon with another visible bounding area that has a background or a border might (emphasis on might) indicate that it can be acted upon, but does not at all convey its purpose.

That’s a good point, an icon used within a link may or may not be considered a visual indicator in itself, and whether someone understands it will vary by person/tester. Applying borders (or anything pre-defined) may or may not help.


> Why is the second sentence necessary?

I don’t think it is, unless someone knows why it was there (and doesn’t overlap with 1.4.11) then we can remove it.

Overall, for the SC text aimed at providing visual indicators by default, there is a fair bit of work that needs doing, probably on the Silver timeline:
1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JanMar/0031.html


Cheers,

-Alastair