Hidden Controls (3.2.7): clarify definition of process and controls needed to progress or complete a process

[smhigley]

The normative language of the standard presents a number of interpretive challenges as the definitions of “process” and "controls needed to progress or complete a process" are so broad that almost any control in any context could be considered in scope.

The understanding document adds confusion to this by saying the following controls are in scope:

• buttons for deleting or forwarding an email
• a form submit button if all required fields are completed and valid
• controls on a video that is part of a training
• An edit button for an editable section of content within a web editor

But excluding these controls as not in scope:

• controls on a standalone video that is not part of a training
• controls needed to operate a web chat UI or carousel
• delete/forward buttons on an email, if there are additional non-hidden delete/forward buttons when the email is opened or in another part of the UI

There seems to be some subjective hierarchy of essential and non-essential processes here, but we (my colleagues and I) are having trouble attempting to find a robust, objective definition that we can apply to our own products. Although we all have our own subjective opinions on what controls should not be hidden, we haven't been able to understand the normative distinction in these examples:

• Using a web chat is not considered a process, but using an email client is.
• Watching a video is not a process, but deleting an email is.
• Watching a video because it contains information you need to know is not a process, but watching a video because it is used in a training is.

Is there an objective definition that can better delineate what counts as a process across different types of UI?

[RobGallo]

While the intent of this criterion is obviously positive, this language needs more time to bake before making it a world-wide standard.
if the W3C definition of "process" is truly intended, this criteria will only apply to multipage forms. Which makes e-mail, blog editting, searching a shopping web site, operating a social media site, indeed almost every modern activity on the web apart from shopping carts, training material, and TurboTax, exempt. If the intent is to cover something broader than shopping carts, training materials, and wizard-style interfaces, then the boundaries of what is or is not a "process" are practically infinite.
Objective boundaries need to be drawn in the normative language because the negative impact of subjective language in the normative portion of a criterion is hard to under estimate when companies across the world will interpret "process" differently.

[AidanA11y]

Could this SC be extended to include all controls/actions? Otherwise it leaves it to interpretation which non-'process' actions are OK to exclude some users from performing.

As I see it, all controls need a persistent onscreen affordance without requiring a user touch/hover/tab to discover the functionality (or a user-selectable mode that enables this behavior).

One use case I have found useful to describe this concept to teams I support is voice control. The user should be able to see what the website/app can do so that they can speak to action that. How else would they 1) know the feature exists or 2) action the feature? Once the control is persistent it makes it available to assistive technology from the start.

Apple solves for this use case in an interesting way... Some iOS apps like Notes hide the ability to search or filter from the default view and the touch user can reveal these by dragging down the screen. There seems to be no other way to reveal those controls. However when a user has accessibility features like VoiceOver or Voice Control enabled those same controls will show onscreen in the initial view (ie persistent, without needing an interaction) . To try this be sure to first turn on VO or VC and then open the app, it wont work if you turn on VO/VC with the app already open.

The iOS example raises a couple possible concerns: it doesn't address a user who is not running one of the accessibility services but needs to know what the app can do; it also seems to rely on detection of the accessibility service running. A controllable setting/mode for this behaviour might be helpful, but the user would of course need to discover that mode.

I suppose some of my example might be covered by 2.5.1: Pointer Gestures, but I hope it still illustrates the point relating to hidden controls.

[alastc]

Hi @smhigley,

Thanks for raising this. The latest version uses a different approach which focuses on the information for that control being available is visible. There is no use of process.

I'll close this as the source of the issue is gone, but please do raise any new issues on the new text, it will be going out for review again.