Re: Visible controls - Design canvas exception

Hi Sarah,

I think we’re broadly agreed on the goal, which is (1) from below, but trying to use (2) to make some progress.

I like Jon’s suggestion that anything which has any action can have other actions, so long as you know what’s actionable initially.

However, what we’re finding is that people have different knowledge / context / assumptions about what makes a visible indicator that something has an action available. Or “recognize something is actionable”, which I’m not sure how we would define.

I had thought it was reasonably straightforward, but when I came across a few hover examples, then collected a few more, I really struggled to work out what would count.

The knowledge and experience I bring to an interface, to understand how to interact with it, is different from others. It is probably very different from the people this SC should benefit.

I was hoping that someone would be able to see something I couldn’t, that allowed for a straightforward evaluation of what a ‘visible indicator’ would be, but that doesn’t seem to be possible ☹

At the AAA level (which allows for greater design constraints) I could see something like MichaelG’s proposal<> in “April 5 attempt to constrain significantly” working, if it also included that the components are shown on hover.

Kind regards,


From: Sarah Horton

Hi, Jonathan.

Just coming back to this after the call today. There seem to be two concerns we are trying to address with this SC.

  1.  Making sure actionable elements are recognizable as actionable.
  2.  Making sure controls that display on hover are available through another mechanism.

My understanding was that the primary intent of the SC was to address the first concern of making actionable elements identifiable/recognizable and that’s what I took away from that subgroup activity<>. The language proposed at the end of today’s meeting seems focused on addressing the second concern of making hidden actionable elements available through a mechanism in addition to hover, which arguably could be said to be covered by SC 2.1.1: Keyboard.

I believe one reason we are having difficulty moving forward and coming to agreement on the examples is that we have different ideas about which concern we are trying to address.

Maybe we could ask COGA if the intent is to address one or the other of these concerns, or both. And if it’s both, maybe we could try to address them separately, which might make it easier to move forward. Users first need to recognize something is actionable.

Thanks for all the great work/thinking on this!


On Mar 31, 2022, at 7:27 PM, Jonathan Avila <<>> wrote:

I agree this comes down to what is the signifier of the availability of invisible components.  The identifier of the component itself may or may not be enough as David mentions.   What a control does is a separate but related issue.  For example, on iOS I get a missed call notification – I assume tapping on it will take me to the missed call details – but instead tapping on it places a phone call.

Text can be a signifier in certain contexts like menus or when it has a different background, or is placed outside of a block of text – but this can be problematic for some where reading and interpreting whether the text contains a verb is an issue.  It’s also an issue as discussed when similar text acts as a link in one place but in another it acts as an expand control such as in your menu example.  I think this comes back to David’s primary action theme.  Some components by nature have a primary action that discloses invisible actions and in that case the standard signifier is acceptable – but in other cases where there are dual actions or where the primary action – e.g. text only doesn’t match then it’s an issue.  This does in some ways take us back to where we started.

Is knowing that all non-grayed out items in a menu are actionable enough regardless of knowing what the action will do?  That is – if you know the item has an action associated with whether it is to perform an action or to expand more items you at least know it is actionable.  Knowing what will occur next is a separate but still important aspect.  But when items don’t look actionable at all yet have actions on hover/focus the user doesn’t know to even try that route.


From: David MacDonald <<>>
Sent: Thursday, March 31, 2022 6:21 AM
To: Alastair Campbell <<>>
Cc: Wilco Fiers <<>>; WCAG list <<>>
Subject: Re: Visible controls - Design canvas exception

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 Alastair

I agree these are tough edge cases and we can expect an array of results on pass/fail on some of these (low inter-rater reliability).

However, for me the big takeaway from this exercise is the concept of "primary function" of the control.

- The usual category of failure of this SC would be when there is nothing there at all identifying that there is a popup, and you discover it by hovering around.
- Then there will be a category of failures where the text, image or icon has another primary purpose which can be confusing for some users.
- Then there will be some squishy ones, where we need to carve out exceptions around known conventions (i.e, considerations for these could be hovering over a video, table editing, or perhaps a tile)

David MacDonald

CanAdapt Solutions Inc.
Mobile:  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 Wed, Mar 30, 2022 at 9:04 AM Alastair Campbell <<>> wrote:
Hi David,

I won’t comment on whether I agree or not (I think it will be a survey question soon), but to clarify some of the examples:

> 6) its a menu, text identifies the popup content

What about the items in the same menu that don’t have a pop-out menu? (E.g. comments.) How can it be an indicator when it works, but not an indicator when it doesn’t have the pop-up?

> 8) tick control: the purpose of the image is to be selected

If you click on the image (not the tick), the image opens full screen, so I’d say the selection-ticks are not the primary purpose.

> 9) Hover over thumbnail to play. Pass because thats a primary purpose

Play is one option, but it also has ‘edit’, ‘select’ and ‘more options’ controls, do they pass as well?

> 12) Fail: Heading text has a different primary purpose

It is also functionally a link and takes you to a ‘show all’ for that category, so it is multi-purpose.
(I think it’s a band-aid feature making up for the headings not looking like links.)

13) Hovering over initials in Teams: I think we need a convention that if there is a headshop or initials, that interacting with that head shot will tell you more about them.

I’d also argue that hovering over rows in a table (the next two) to show more options is a convention.

> 16) Edit a table

The last example is tricky, you get some controls on-hover (on the left), but clicking into the cells allows editing.

Thanks for reviewing the examples, I’ll update the notes around them.


Received on Tuesday, 5 April 2022 21:42:57 UTC