- From: Jonathan Avila <jon.avila@levelaccess.com>
- Date: Tue, 14 Jan 2020 13:15:59 +0000
- To: WCAG list <w3c-wai-gl@w3.org>
- Message-ID: <6E067184-2DA7-4596-B1C1-953E4C5E9760@levelaccess.com>
It seems like splitting the criteria over two levels as proposed is a good solution - I had considered the same split after the last call. Jonathan Sent from my iPhone On Jan 14, 2020, at 4:20 AM, Alastair Campbell <acampbell@nomensa.com> wrote: 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. Jake wrote: > if a icon is used for a button (as an example) it would be fine to show a tooltip on tap & hold if there was no other functionality already present. If that works, I haven’t seen an example. Google docs toolbars are a good example of this SC on desktop, with very clear labels appearing on focus/hover. However, open that on a touchscreen (in a browser) and the custom tooltips appear & disappear very quickly and are under your finger. We really need an example to know that this is feasible. > We might take a look at splitting the SC, a AA (hover / focus) and a AAA (more)?! Conceptually that makes sense to me, I’m just not sure how the language would work to differentiate them. Perhaps something like: AA: “For icons that act as labels or instructions, a mechanism is available to display a text equivalent visually, on or before the first occurrence of an icon on the page. If the mechanism is triggered by interacting with the icon, it can rely on hover and focus events.” AAA: “For icons that act as labels or instructions, a mechanism is available to display a text equivalent visually adjacent to the icon.” (Also removing the legend mechanism.) Cheers, -Alastair ________________________________ From: Alastair Campbell <acampbell@nomensa.com> Sent: Monday, January 13, 2020 11:23 AM To: Abma, J.D. (Jake) <Jake.Abma@ing.com> Cc: David MacDonald <david100@sympatico.ca>; WCAG list <w3c-wai-gl@w3.org> Subject: Re: WCAG 2.2 status - Icon Description Hi Jake, Tapping on something to find out what it is seems ok to me, but it does seem odd to find out what an interactive icon does only at the point you activate it. Unless there was some kind of tap & hold to see the tooltip, tap to activate? But then how would someone learn that is how it works? It seems like the kind of thing that wouldn’t help the people who need it. The hover/focus solutions seem reasonable, would we be prepared to allow for it to work in some devices but not others? Cheers, -Alastair From: "Abma, J.D. (Jake)" For me, on hover and focus seem fine, on click/tap and enter key not as this is a bit of odd behavior (activate a UIC and then show a tooltip? or clicking on NON interactive elements?) Previous example was (as I remember) also a modal dialog and the tooltip was hidden under the overlay. At the moment this one still doesn't work on Android phone. -------------- Also decorative / additional / supportive icons (part of label like content) NOT used as interactive label icons should not per se have tooltips. -------------- Only the first of an icon, somewhere on the page (not necessary in the same landmark) also doesn't seem to fix the repetitiveness of icons in contrary to how it might work for abbreviations and alike. ________________________________ From: Alastair Campbell <acampbell@nomensa.com> Sent: Wednesday, January 8, 2020 11:36 AM To: WCAG list <w3c-wai-gl@w3.org> Cc: David MacDonald <david100@sympatico.ca> Subject: WCAG 2.2 status - Icon Description Hi everyone, Another SC-specific follow up, this one on Icon Description. The issue it is trying to solve is how to understand icons that do not have visually associated text labels. The main theme of the comments/discussion was around how well it works on touch platforms. For example, where an icon is a trigger for a menu, or a link, how would you present a text label? (Which is fine on desktop with a mouse or keyboard focus.) David did include examples which appear to cover most people’s concerns, but I’m not sure if everyone has had time to consider those? * Example A - A keyboard and mouse operable tooltip that shows on hover and keyboard focus https://codepen.io/Moiety/pen/LaPvWy * Example B - A keyboard and mouse operable tooltip that shows on click/tap and Enter key https://codepen.io/dmacd100/pen/eYYBWNK There are some text-edits/suggestions in the comments, but the main thing is: Do people agree that it would improve the situation for people with disabilities, and that it applies to all content across all websites & technologies? If you could consider that and please update the Survey: https://www.w3.org/2002/09/wbs/35422/icon-desc-acceptance/ Then we’ll know whether to progress. Kind regards, -Alastair Doc: https://docs.google.com/document/d/1HzSsCGelWfz_Z-M7NyUzJOvl1A1kAStyl8epYdpZhoA/edit#heading=h.u26dvsexm72w Minutes: https://www.w3.org/2020/01/07-ag-minutes.html#item06 ----------------------------------------------------------------- ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. ----------------------------------------------------------------- ----------------------------------------------------------------- ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. -----------------------------------------------------------------
Received on Tuesday, 14 January 2020 13:16:22 UTC