Re: WCAG 2.2 status - Icon Description

I am not directly advocating to place the SC on hold or defer to Silver.
I simply have a few concerns with the current wording and my understanding thus far.
I am reading the entire comment history in the doc; inspecting the CodePen examples; and watching the referenced ID24 clip.

Once upon a time in iOS, a long-touch triggered the same pointer event as hover. This was my reference in previous comments. Apparently this is no longer the default behavior. Instead, it triggers the contextual menu of the OS. To use this technique, appears to require the combined use of the Touch Events API and Pointer Events API.

Overall, it currently seems insufficient to solve an understanding problem (what does the icon mean?) with a new understanding problem (is the icon itself an affordance to display its own description?), particularly in the context of it being used as a label or instruction for another action. Have any of the examples been tested by people with cognitive issues?


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: Alastair Campbell <acampbell@nomensa.com>
Date: Monday, January 13, 2020 at 11:56 AM
To: "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>
Cc: WCAG list <w3c-wai-gl@w3.org>
Subject: [EXTERNAL] Re: WCAG 2.2 status - Icon Description

> Touch screens actually have more available actions than fewer. They lack hover, match focus, but gain long touch, force touch and gestures.

In terms of what can be applied with standard events on a web page, I think it is still fair to say we don’t have an equivalent option to hover/focus.

I wouldn’t expect to be able to do a long-press or gesture on an icon to get a description, it would probably activate the link. However, that expectation is there for hover. (Is force touch still a thing?)


> [having a toggle] would extend to a method that could be queried, like prefers-icon-labels that could globally toggle the display state of the text description.

Ok, but we’d have to put this SC on hold whilst that query was created. If the toggle isn’t the primary method, we don’t have a primary method that people could implement this year on a WCAG 2.2 timescale.

The question now is whether this (or some variation on the current wording) is a useful SC to add.

Would web interfaces be more accessible if they were required to:

  *   Show text descriptions by default?
  *   Show text descriptions on hover and/or focus?
  *   Provide a toggle to show text descriptions?

Or, would requiring any of those do more harm than good? I.e. the solutions are not good enough yet.

Is it be better to put this idea on the Silver track and/or campaign for a personalisation/preference for visible text descriptions?

Cheers,

-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.