Re: WCAG 2.2 status - Visual indicators

My interpretation of “conveys its purpose” is still in a narrower scope. For example, link text on a bank site that states “make a deposit” does not have to provide an affordance to the purpose of a deposit. It simply has to be clear that the purpose of a link is to change the current context to one where the deposit can be made. However, it should also be clear how that change of context occurs. Does it load a new page? In a new window? Does is open a dialog? Toggle the content or state of the current page? Even WCAG 1.0 described “providing understandable mechanisms for navigating within and between pages.”

This is why I also raised the concern of visual design trends that remove or reverse affordances. If this example “make a deposit” link has the visible affordance of a button, now it is unclear that it is even a link, let alone how the context is changed. It may instead be confused with a button that actually submits a deposit (even when the user has not completed any form or uploaded an image). An element that has a visible indication that it can be acted upon may not in many cases convey its purpose.

So, it sounds like the real goal here is something far simpler, like:
“Each user interface component that can be acted upon provides a visible indicator which conveys it can be acted upon.”

But if so, then it does not solve for or attempt to solve for: what action can be taken; in what state; if the action has been taken (feedback); if the conveyed action aligns to the actual action; how visible the indicator is; and of course, if it is understood.

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 <>
Date: Monday, January 20, 2020 at 11:09 AM
To: David MacDonald <>
Cc: WCAG list <>
Subject: [EXTERNAL] Re: WCAG 2.2 status - Visual indicators
Resent-From: <>
Resent-Date: Monday, January 20, 2020 at 11:09 AM

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.



From: David MacDonald <>
Date: Monday, 20 January 2020 at 15:52
To: Alastair Campbell <>
Cc: "Hall, Charles (DET-MRM)" <>, WCAG list <>
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.

David MacDonald

CanAdapt Solutions Inc.

Tel:  613-806-9005



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Sun, Jan 19, 2020 at 5:53 PM Alastair Campbell <<>> 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:



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.

Received on Monday, 20 January 2020 20:27:50 UTC