Adobe Comment on 3.2.7 Visible Controls

[awkawk]

We have significant concerns about this proposed SC. As written, this will be difficult or impossible to implement for many authoring tools where content in a design canvas has dozens (or thousands) of editable objects. Adding a visible indicator to each object on a design canvas would likely make the content far less understandable to users, and may make the user interface overwhelming to some users. To address this, we recommend adding an exception for User Interface components within the design area for a web page that is being used to author content.

We also feel that it is very important to highlight the note more by making it normative text to indicate that UI Components that are made available via progressive disclosure are not in scope.

These issues must be addressed in order for Adobe to support inclusion of this SC.

[alastc]

many authoring tools where content in a design canvas has dozens (or thousands) of editable objects.

Could you confirm that, in that scenario, there are controls that appear on hover/focus?

Just asking as I had thought the typical interaction was to select an element (e.g. click on it) and then controls appear.

[mraccess77]

I think what may occur in authoring environments is that you click on an element to focus it and then options become available in menus or around the element like resize controls. Until you click/focus the element these things are not visually present to tell you that you can resize the element or perform actions on it. I'd say that perhaps just a border would be enough to communicate it's action in these cases - something like the border in PowerPoint or Google slides to make it appear as an editable object.

[lseeman]

coga feels that it need clear how to reveal hidden controls.
Clear: can be an icon or toggle familiar with users" with text or personlization sematices,
Clear instruction on how to reach the control, that are on the page before or adjacent to the control is enough

[alastc]

Andrew wrote:

this will be difficult or impossible to implement for many authoring tools where content in a design canvas has dozens (or thousands) of editable objects.

I'm really struggling to find an example, most of the authoring tools I've tried (web and non-web) rely on click or text-select before controls appear.

@awkawk is there any example you had in mind?

[alastc]

My understanding is that there can be controls available on focus, which if you think about arrowing/tabbing through 100s of items on a canvas would be very necessary.

I think there are two possible solutions, either:

• The 1st exception (alternative buttons) probably applies, because anything available on focus is likely to be available not on focus, elsewhere in the interface.
• We remove the focus aspect from the SC. That would take a bit of work to avoid the loophole that @mbgower pointed out, I think we'd have to say something like:

"When user interface components are invisible until hover makes them visible, provide a visible indicator that the components are available. Except when:

• The same functionality is available for pointer input through a component on the same page, or on a different step in a multi-step process, without requiring pointer hover or keyboard focus to make it visible;"

[mraccess77]

Regarding removing the focus bit - It seems to me that the same issues affect keyboard users and requiring them to focus all controls to discover additional content seems to chose one group over another.

Regarding the specific concern from Adobe - it seems like there could be a solution such as a button or hot key that could toggle the the items that are interactive to contain an indicator. Also there may be a pane where the objects are listed some other exception for situations where menu items exist, or some instructions or some option that we could allow that would help the user understand how to use the interface.

[alastc]

It seems to me that the same issues affect keyboard users and requiring them to focus all controls to discover additional content seems to chose one group over another.

The problem this SC is trying to solve is for people with cognitive issue not knowing how to access functionality. If you use a keyboard (-like device) and have to tab through all the controls (and see them as they appear), that isn't the same issue.

In fact, requiring things to appear on focus may make things worse, there would be many more controls to get through.

You could have an option to show-all, that's one of the exceptions, but I consider this a false positive as the interface is not failing the intent of the SC, but is failing the letter.

[patrickhlauke]

The problem this SC is trying to solve is for people with cognitive issue not knowing how to access functionality. If you use a keyboard (-like device) and have to tab through all the controls (and see them as they appear), that isn't the same issue.

arguably though, users may not even remember that a particular control/functionality existed, or roughly where it was in the context of the entire page's focus order. sure, they'll encounter it if they just keep tabbing - eventually.

however, i do see how without this exception, we'd make long-standing approaches like visually-hidden (but visible on focus) skip links basically illegal (or requiring additional work for a site to offer some "always make the skip link visible"), which is likely not a good move (and would get a lot of pushback from designers/developers, no doubt)

[mraccess77]

• We already had an exception for skip links that were focused and I think we should keep that.
• This SC very much benefits users with low vision who need those indicators as well as moving around the mouse over every item is problematic.
• Many people have multiple disabilities and a person with a cognitive disability could certainly be a user of the keyboard as well
• People don't just tab through everything with the keyboard - there are hotkeys to move within many web apps and there keystrokes with extensions to move between landmarks, I use contro+f to search and then tab to skip over content - so I don't think people simply tab through everything anyway.
• @alastc states that making things appear on focus makes things worse - this SC never required things be visible on focus - it said when things appear on focus or hover then you needed to have indicator - so it was certainly not promoting that.
• Not including things that have additional controls on focus only is a problem for users with cognitive disabilities and by removing that requirement we are not helping users with cognitive disabilities

[patrickhlauke]

@alastc states that making things appear on focus makes things worse - this SC never required things be visible on focus - it said when things appear on focus or hover then you needed to have indicator - so it was certainly not promoting that.

yeah sorry, i should have said (assuming that's in response to my "make skip links visible") that authors could add a mechanism to make things always visible, or make indicators for these things visible (i.e. not the control itself, but some kind of arrow, hint, whatever)

but yes i do agree this seems to cause a weird imbalance for (partially or fully) sighted keyboard users, and even more so if they're keyboard users with cognitive disabilities.

[rachaelbradley]

Draft response. In situations where all subcomponents of a single component (such as a design canvas), text explaining that all contents are editable is a sufficient indicator. PR #2234 adds text and a technique to the understanding document to clarify this.

[alastc]

Visible controls has been deferred (implemented in #2353), so closing.