Clear controls

[lseeman]

SC Shortname:

Clear Controls

SC Text

Clear controls: Visual interactive controls are clear or clear controls are easily available though personalization that conforms to all of the following:

• Interactive controls are visually discriminable and have a border around the interactive area of the element with a contrast ratio of at least 4.5:1 with its background, or has fill that provides a contrast ratio of at least 3:1 from the background. It is sufficient for links to be consistently underlined.
• Interactive controls are available in a standard style that indicates how they can be used and what action it will trigger or have clearly labeled instructions that explains their use.

An exception is available if the style is an essential part of the main function of the site, such as for a game.

Suggestion for Priority Level (A/AA/AAA)

Level AA

Related Glossary additions or changes

easily available (or easily available mode or setting)

• Can be set one time with as wide a scope as possible (such as using the standards of the OS, ETSI or GPII when available) and
• with the option to save or change the setting, were available interoperability but also for a scope of the set of web pages and
• is reachable from each screen where it may be needed, and the path and control conforms to all of the document.

What Principle and Guideline the SC falls within.

Principle 3, The COGA task force suggests that updates to this principle apply to content other than text content only.

Description

The intent of this success criterion is to help a person understand which elements in the content are interactive. The success criterion would be met by ensuring there are sufficient visual affordances to indicate the boundaries of an element and how to interact with it. This will not only set it apart from plain text content that is not interactive, but also indicate the clickable area for easier selection. We want to avoid people accidentally triggering events and ensure that they know how to trigger the events that they need.

Note that visual affordances can take different forms. One common visual affordance is to display an underline under a link. Another is to provide borders around interactive elements that have sufficient contrast to show the active clickable area for the element.

Benefits

Many people cannot easily learn design metaphors that cause interactive controls to have subtle visual differences from the rest of the content such as techniques found in flat design. When interactive controls have understandable visual affordances, users can more easily locate desired items to interact with and know what that interaction might do. In addition, when users can easily see the active boundaries for controls it improves the ability to select that control via a pointing device or by touch. This is discussed fully in the COGA Flat Design Issue Paper

Many people cannot easily learn new design metaphors or remember things that they have learned for example, people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or impossible to know what the interaction may do and to learn new controls. As one user with mild dementia stated "I have great difficulty remembering things, working things out, and interpreting things."

As long as interfaces are familiar and clear the user can continue to use the Web.

Related Resources

Resources are for information purposes only. No endorsement is intended or implied.

• Gap analysis section 2.3.1 Issues with Flat Design
• User needs Table (Table 5: Simple and Clear Interface)
• See also : User needs Table:6, 7,8 and 9
• Background research document
• Semantics for adaptive interfaces
• COGA Techniques Techniques for the Cognitive and Learning Disabilities Accessibility Task Force (COGA) Section 2.6.1 Use clear visual affordances

Testability

1. Confirm that links are underlined or can be underlined via personalization
2. Other Interactive controls - Confirm one of the following:
   1. A border is present around the interactive area of the element with a contrast ratio of at least 4.5:1 with its background,
   2. or has a fill that provides a contrast ratio of at least 3:1 from the background.
   3. The sufficient background or border is available via personalization (not more then one click or interaction away)
3. Confirm one of the following:
   1. Controls are available in a standard style and function such as HTML controls or standard controls for the native platform
   2. Controls are available as standard controls as described in a WCAG technique
   3. Detailed instructions on how to trigger each event are easily available (not more then one click or interaction away)
   4. One of the above is available via personalization
4. For non-link elements, ensure there is either a border, or a fill that:
• Outlines the active area (e.g. clickable, touchable part) of the element. Note: if an element has multiple actions or active areas, each has an ` border or fill.

Techniques

1. Existing technique: G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them">
2. New technique: Providing a border around the interactive area of the element with a contrast ratio of 4.5:1 with its background, or has fill that provides a contrast ratio of at least 3:1 from the background

Some examples of interactive elements where the border would be most helpful:

• Icons
• Buttons
• Text input fields
• Switches
• Sliders
3. New technique: Providing an underline to identify links
4. New technique: Using personalization to enhance visual affordances on interactive elements
5. New technique: Using standard controls
6. Adding semantics to enable personalized controls
7. Adding instructions
8. Adding semantics to enable instructions

Working groups notes

Could be merged with the Low Vision and Mobile TF SC such as “Metadata On Hover” and is “Content that appears on hover should not obscure the triggering element or other content.”

Alternative wording

Interactive controls use a visual style that makes it understandable that the controls are interactive and indicate the active area for the control with the following exception:

• Customizable: The visual affordances for interactive controls are available through personalization.

Original wording: Interactive controls are clear or clear controls are easily available though personalization Boundaries on a interactive controls and icons should have a sufficient color contrast of 1.5 (visual only) or can be emphasized in the modality of the user. Auditory emphasis can include slightly louder content, a change in the pitch or a change in the voice.

[joshueoconnor]

Assigned to Neil Milliken - https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

[NeilMilliken]

In the 2nd Bullet point of the SC text I think that we need to define what a standard control is and add it to the glossary.

"Interactive controls are available in a standard style that indicates how they can be used and what action it will trigger or have clearly labelled instructions that explains their use."

As a starting point for discussion I am suggesting the following:

"The qualities or properties of the control define its possible uses. It is clear how it can or should be used and what action it will trigger. Actions and actionable items that can be interacted with should have a clear visual style that indicates how to interact with them e.g. buttons that look like buttons. "

[DavidMacDonald]

Is there an overlap with Issue #9 and #10

[NeilMilliken]

Possibly some overlap but much more that does not and ass previously discussed by email best to leave SC intact for now to avoid delay

[detlevhfischer]

Outlining of icons might be left to user-applied styles or browser plugins that force these outlines and might therefore not be the author's responsibility?

For the iconography itself one could probably draw up versions of the most common icons where user research has demonstrated a high degree of recognition. So a test may check whether the icon used on a site maps to any one of the common 'standard' implementations known to work well. The aim would be to identify icons that fail to be easily recognisable especially when they are used for one of the main navigational functions for which conventional solutions exist (home, search, arrow left/right/up, login/logout, user, settings cog, etc.)
I write this with trepidation as I know that there are many versions of these icons out there, and the assessment whether a particular desgin 'sufficiently conforms' to the approved standard icons is likely to be somewhat subjective.

[joshueoconnor]

@NeilMilliken Can you give me a status update on this please?

[joshueoconnor]

New Pull request for this issue #101 thanks Thaddeus @inclusiveThinking

[awkawk]

I don't like using "clear" but it is apparent that the goal of this SC is that controls need to address the two bullets in the SC.

The first bullet seems to be redundant to the "User Interface Component Contrast" SC proposal. Can these be combined? I'm not sure where they differ.

The second bullet is a problem in that it seems to require that just standard controls are used. This would have been a problem not too long ago when there was no way to introduce a set of tabs on a web page. If this was put in place then we wouldn't be allowed to introduce a set of tabs because it would not be "standard". Is that correct, or am I misunderstanding the text of the SC?

Related to the definition, I think that this is getting into the user agent space more than WCAG can do. The whole "a mechanism is available" phrase in WCAG 2.0 speaks to the potential for users to accomplish something, but adding in the "easily" aspect of it introduces testability issues. If the functionality described was available as a browser setting with a global scope, how would we also require that the setting be available from each screen where it is needed? Does selecting browser preferences from a menu equate to "available from each screen"?

[NeilMilliken]

I agree that bullet point 1 is pretty well addressed by user interface component contrast.

I am most concerned about bullet 2.

Would you prefer unambiguous instead of clear?

I would be happy with Unambiguous if my dyslexia would allow me to be confident spelling it.
Once again I think success is related to:

Understanding

• that there is a control present

• What action it triggers

"The qualities or properties of the control define its possible uses. It is clear how it can or should be used and what action it will trigger. Actions and actionable items that can be interacted with should have a clear visual style that indicates how to interact with them e.g. buttons that look like buttons. "

So for example if we take the now commonplace Hamburger Menu the three lines may be visually discernible but to many users with cognitive accessibility needs often do not know that it is a menu. We may conclude that hamburger fails unless it has some indicator that it expands.
Taking on board Detlev's comments I think we can reference (and periodically update) commonly occurring icons) this would only be subjective in the same way that meaningful alt text is subjective,

Whilst much of what is described could be applied at a Browser/OS level I don't think that this is just a user agent issue we want controls by default to be understandable as many people with cognitive accessibility needs will not know how to set this. so if you think that having the mechanism easily available is undesirable we should be placing greater emphasis on ensuring that the controls are unambiguous.

[mbgower]

Interactive controls are available in a standard style

Here are completely vanilla HTML list boxes, as displayed in four different browsers.

• Three are expanded by default
• Two have visible but greyed out scrollbars
• Two have colour selection indicators for the list item with focus (both of which fail minimum contrast)

In short, the only thing all four components have in common is that they are preceded by the same text label.
Tell me which of these traits is the "standard style"?
Once the debate on that has settled, is an author responsible for making them all look the same, regardless of browser?
Now, imagine the debate you are going to get when instead of trying to apply this measure to default styles of a standard HTML component, you attempt to define what the "standard style" is of a more complex widget.

[NeilMilliken]

Thanks for your comments Mike I am certainly not saying that it will be a stroll in the park to define standard. You may say that all 4 are standard as they are commonplace. However, only 2 of these are unambiguous. The pressing need is for users to be able to understand that something is actionable and how to take that action.

[jim-work]

As the four examples above are vanilla HTML, surely they are the standard style for the browser in use? As such they conform with 3.i in the test section. If a user is using their browser of choice then the control should be unambiguous. An author should not be responsible for making them all look the same, regardless of the browser in use. However, if the author restyles them to conform to a standard appearance they should be responsible for ensuring that they meet this SC. If icons are used we would have to take on Detlev's concerns. Non-standard icons are a genuine concern for users with dementia in particular and users with COGA issues in general.

As for the second bullet point:
"Interactive controls are available in a standard style that indicates how they can be used and what action it will trigger or have clearly labeled instructions that explains their use."

Would inserting a ";" help with the clarity:
Interactive controls are available in a standard style that indicates how they can be used and what action it will trigger; or have clearly labeled instructions that explains their use."

If you don't like the idea of instructions on the example of tabs used earlier, you can fall back to the "easily available" option in providing an alternative.

[mbgower]

You may say that all 4 are standard as they are commonplace. However, only 2 of these are unambiguous. The pressing need is for users to be able to understand that something is actionable and how to take that action.

Right, and this is the crux of the problem: a standard style is not necessarily consistent (as demonstrated) or clear. There is nothing inherently clear about a thin line flashing in the middle of a text field. The only reason anyone understands that is through explanation, convention or investigation. Same goes for the behaviour of pretty much any native HTML component; why should underlining mean I can click it? etc.

So when we parse this sentence there are a bunch of assumptions made that don't necessarily follow one another:

Interactive controls are available in a standard style that indicates how they can be used and what action it will trigger or have clearly labeled instructions that explains their use.

• "standard style" is not synonymous with "default"
• "standard style" does not automatically "indicate how [something] can be used or what action it will trigger"
• given this, it would be necessary to 'label instructions' for every control from an assumption a user has never encountered it before or does not understand the conventions

I would suggest that there is a solution for the problem this SC is trying to address, and it involves personalization. If an author has passed 1.3.1 and 4.1.2, then the state, name, role and value for all interactive elements are programmatically present.
A browser feature, plug-in or style sheet could be created that offers a number of possible features:

• apply a consistent style for any role
• add in the role as visible text
• add a description of every interactive element's use
• offer an ability to shut off such assistance at a granular level (a series of grouped checkboxes, for instance)

The W3C could even create such a script/feature and offer it for free as a plug-in or piece of code that could be injected into a web page, until such time as the user agents adopt their own solutions. But making it the author's responsibility to construct such a thing seems unreasonable.

For things that do fall within the author's responsibility, I'd argue we already have a number of SC that achieve this:

• 2.4.4 Link purpose. "The purpose of each link can be determined from the link text alone or..."
• 2.4.6 Headings and labels. Headings and labels describe topic or purpose.
• 3.2.4 Consistent Identification. Components that have the same functionality within a set of content are identified consistently.
• 3.2.2 Labels or instructions are provided when content requires user input.

A gap that I think needs to be plugged is an SC that directly addresses "Clear Instructions". As things stand, it is perfectly allowable to have a useless instruction that meets the current guidance. I've been working on a mash-up of overlapping parts of Plain Language, Clear Text and Voice, Clear Purpose, and Help that addresses this.

[lseeman]

New wording
unambiguous controls: A mechanism exists for rendering visual interactive controls in a standard format unless they have clear instructions that explain the interaction.

An exception is available if the style is an essential part of the main function of the site, such as for a game.

(I change clearly labeled instruction that explain the use because mike found that ambiguous with liked text)

---

Then we have to identify standard controls with a minium testable criteria. This will take us a few weeks but it will be along the lines of:

standard format: A format that identifies their roles. At a minimum this includes:

• Buttons and links have a clearly identified outline or are underlined unless they are in a tool bar or menu bar that has a clear outline (either via a border or background color) and only contains elements with the same role and interaction patterns. (side note: tab items and toolbar items in the same bar would fail) .
• Options are are associated with a check box, radio box or are in a list box

[lseeman]

@mbgower I do not understand why you would find an overlap with 2.4.4 , 2.4.6 or the rest of your list. I do not see any

[lseeman]

I just spoke to mike. we should add a sentence in the discription that explains the diffrnece with
3.2.2" Labels or instructions are provided when content requires user input"
3.2.2 typiclay is used to add to instuction on the data format and you can can use a lable and meet the requirment. Here we are talking specificly for insructions about how to interact with an element or control, if that interaction is not clear from the format

[mbgower]

explains the diffrnece with 3.2.2

For clarity, the referenced SC is 3.3.2 Labels or Instructions, not 3.2.2.
3.3.2 is directed at minimizing user input errors. It can involve instructions, but those are primarily intended to ensure "users know what input data is expected"
Clear controls addresses the interaction with the control itself.

[goodwitch]

I agree that the color contrast piece of this proposed SC should be carved out of this and instead handled by the proposed SCs "User Interface Component Contrast" #10 and "Graphics Contrast" #9 (in answer to questions/suggestions made by @DavidMacDonald @awkawk @NeilMilliken )

[alastc]

(Replicating my survey comment here).

I don't know what a "standard format" is for visual interactive controls? From reading the description, it seems to be about differentiating links and interactive controls from content. It is good it has been separated from the LVTF SC, but I wonder what is left?

Trying to define 'standard format' seems like a very difficult option, especially since flat design might be the platform standard!

The issues with flat design are interesting, it feels like there are three levels of solution:

• Conform to 1.3.1 (i.e. use the right HTML for the right element).
• If you don't conform to 1.3.1, identify interactive controls in a standard way.
• If you don't do either of those, provide a control for a "high affordance" version.

Translating that to WCAG format, I'd suggest taking an approach like:

For interactive controls that are not visually differentiated from other content, a mechanism is available for highlighting the interactive controls with visually distinct borders, backgrounds or icons.

Note: a mechanism for highlighting interactive controls is to use platform standard controls.

[NeilMilliken]

I would say:
"interactive controls must be visually differentiated from other content.

The purpose of the controls be made unambiguous to the user or they must have clear instructions that explain the purpose."

If you cannot determine that there is a control how will you know to activate the available mechanis?