RE: Visible controls - Design canvas exception

Hi Sarah,  my recollection is that “Making sure actionable elements are recognizable as actionable.” was the original intent – and which I support – but which we could not get group consensus on 12 months ago.  To allow the SC to go forward the group indicated there needed to be a change in the direction.

The work of the group shifted to Making sure the presence of components that are only displayed on hover or focus have some indicator.   This would mean that a piece of text that was your name couldn’t just show it could be edited on focus/hover but needed to indicate that if it is editable directly it needed to have some signifier that an edit control would appear.   E.g. pencil icon, border, underline, … indicator, etc.

So, while it addresses only part of the situation it was the hope of the group that it did provide some benefit.  One situation we are discussing now is where controls have primary and secondary actions – when does the secondary action which has components that are only shown on however/focus need to indicate that.  In addition, when do icons and other UI constructs inform the user of controls on hover/focus simply by their existence – e.g. the profile icon example.   This last example leads us back to the original discussion of what is actionable – but it is limited to situations where additional controls appear on however/focus and not just any icon that acts like a button.

Jonathan

From: Sarah Horton <sarah.horton@gmail.com>
Sent: Tuesday, April 5, 2022 2:32 PM
To: Jonathan Avila <jon.avila@levelaccess.com>
Cc: WCAG list <w3c-wai-gl@w3.org>
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, 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<https://docs.google.com/document/d/1v9VN9JN7fWIv1fIlBNXRhibMnRavn0M2Bx6AohtZ_jc/edit#heading=h.36v3whzebqn8>. 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!

Best,
Sarah



On Mar 31, 2022, at 7:27 PM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> 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.

Jonathan

From: David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>
Sent: Thursday, March 31, 2022 6:21 AM
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Cc: Wilco Fiers <wilco.fiers@deque.com<mailto:wilco.fiers@deque.com>>; WCAG list <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
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)


Cheers,
David MacDonald

CanAdapt Solutions Inc.
Mobile:  613.806.9005
LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd<http://twitter.com/davidmacd>
GitHub<https://github.com/DavidMacDonald>
www.Can-Adapt.com<http://www.can-adapt.com/>

  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>


On Wed, Mar 30, 2022 at 9:04 AM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> 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.

-Alastair