Re: WCAG 2.2 status - Visual indicators

I have some questions and concerns.

Current SC text: “Each active user interface component provides a visual indicator which conveys its purpose. Where the visual indicator is a underline or an outline shape, the visual indicator has a contrast ratio of 3:1 with at least one adjacent color.”

Is “active” stated to be more clear and direct than making an exception for inactive or disabled elements?
If so, that seems like it could be confused with the active state (:active) triggered by pointer events. The Understanding Doc for 1.4.1 describes this as “…not available for user interaction (e.g., a disabled control in HTML)”. So perhaps something like “Each user interface component available for user interaction…” is still clear enough with less ambiguity on “active”?

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.

Are there any methods, techniques and tests for “conveys its purpose”?
The goal of the SC seems to be for a user to see and indication that an element can be acted upon and understand what the required / expected action is and the what the result should be. A Twitter icon on a page could just as easily intend to convey that the owner of the site also has a presence on Twitter as it could intend to be a link to that presence, or as it could intend to be a button to launch a dialog to compose or preview a message to post to Twitter. 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. The document contains a NOTE that includes “We suggest using familiar visual indicators for the component when possible…”. But this makes a significant assumption about what is familiar. There has been a profoundly disturbing visual design trend over the last decade to make links have either zero affordance or look like buttons. While either fail several SCs, it is unfortunately now solidified as familiar. I could never support a statement that enables this trend to persist.

I provided this quote in response to the Status for the Icon Description SC, and it applies here as well:
“The presence of an affordance is jointly determined by the qualities of the object and the abilities of the agent that is interacting.” — Don Norman
The most important factor of an affordance is understanding. If the SC is to support both visual ability and cognitive ability, there should be a way to measure the later. Is the purpose understood?

Why is the second sentence necessary?
It seems to be redundant to 1.4.11, while also suggesting that if the indicator is anything other than described, it does not need to meet the ratio – which would then conflict with 1.4.11.

There is additional content in the Doc and the discussion thread on “one of the following is true…” which include, user agent or plugin; mechanism on page; and on page load. It seems the “mechanism on page” has a great deal of overlap with the discussion thread on the Icon Description SC, and implies that an element with no visible indicator would pass if there was a mechanism to toggle its state. I don’t like this implication. Any number of scenarios could then exist where a person scrolled past elements that could be acted upon but never knew it and the toggle would only change what is currently in view, and presumably require having to repaint the page to do it. Then, the “on page load” implies that at some point after the page has loaded, it is acceptable to remove the visible indicators. I don’t like this implication either. It suggests that measuring time is also required, which could then also conflict with Guideline 2.2 Enough Time.

Thanks,

Charles Hall // Senior UX Architect
Invited Expert, W3C Accessibility Guidelines Working Group

(he//him)
charles.hall@mrm-mccann.com<mailto:charles.hall@mrm-mccann.com>
W +1.248.203.8723
M +1.248.225.8179
360 W Maple, Birmingham MI 48009
mrm-mccann.com<https://www.mrm-mccann.com/>

[MRM//McCann]
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: Jonathan Avila <jon.avila@levelaccess.com>
Date: Thursday, January 16, 2020 at 4:22 PM
To: Alastair Campbell <acampbell@nomensa.com>, David MacDonald <david100@sympatico.ca>
Cc: WCAG list <w3c-wai-gl@w3.org>
Subject: [EXTERNAL] RE: WCAG 2.2 status - Visual indicators
Resent-From: <w3c-wai-gl@w3.org>
Resent-Date: Thursday, January 16, 2020 at 4:21 PM

HI Alastair, yes, it would be inconsistent with the override but would pass.   I think that’s an acceptable way to keep the proposed SC from not be accepted although we might have to figure out what requirements the author supplied one must look like – which is the thorny situation to cover as we don’t know the different types of controls and thus this takes us full circle back to the concerns raised over mandating a specific affordance for patterns which can take many forms.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Thursday, January 16, 2020 2:07 PM
To: Jonathan Avila <jon.avila@levelaccess.com>; David MacDonald <david100@sympatico.ca>
Cc: WCAG list <w3c-wai-gl@w3.org>
Subject: RE: WCAG 2.2 status - Visual indicators

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Jon,

> if the sample styling isn’t displayed when applied then it can pass by providing it itself directly or via some mechanism like toggle.

So by sample styling, you mean the user’s CSS override? (Done by pluggin or whatever).

My assumption is that the user’s styling would (or at least could) vary between people. It was yellow & black in my case, but could be different for other people.

However, what the site could provide for custom controls could not vary between people, even with a toggle mechanism.

The control is providing a visual affordance, but not one that matches my pluggin.

It doesn’t fail (as it stands), but it would be an inconsistent experience for users.

-Alastair

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 Saturday, 18 January 2020 22:33:43 UTC