Understanding Success Criterion 3.2.7: Visible Controls

Success Criterion 3.2.7 Visible Controls (Level AA): When user interface components are invisible until hover or focus makes them visible, provide a visible indicator that the components are available, except when:

User interface components can be available through other visible components such as sub-menus, edit buttons, tabs, or thumbnails of media.

The working group is interested in feedback about whether there are Components determined by the user agent that should not be in scope.


This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published.


The intent of this Success Criterion is to ensure that user interface components (controls) can be found easily by people with cognitive disabilities, vision loss, and mobility and motor impairments.

Some design approaches hide controls and require certain user interactions (such as mouseover) to display them. Where the hidden controls are needed to complete tasks, the difficulty in discovering the controls can leave some users with disabilities without a way to progress.

People with low executive function, impaired memory, and other cognitive and learning disabilities may not be able to find hidden controls. If a hidden control is needed in order to progress, this can prevent some users from completing a task. Users who discover controls that display on hover may not remember how to show and operate the controls the next time they interact with the site. So even when a user is able to proceed, time on task can be affected for both one-time and repeated uses.

One of the main challenges for people with vision loss is simply locating related controls on the screen, moving the mouse from control to control, and getting the keyboard focus to coincide with where they are looking. This Success Criterion can help reduce that cumulative load.

People with vision loss may not see controls that display only on hover or focus, particularly if they display outside of the viewport. For users who require enlarged or magnified content, the portion of the content in the viewport may be significantly reduced. Low vision users may have 800 x 600 resolution as the default. They may look closely at the monitor from a few inches away due to limited acuity (inability to see detail) or Scotomas (blind spots). They may have a significant amount of head and neck movement while using content. When users don't see something on the screen, they may assume they are missing it — for example, that it’s in their blind spot or hidden in a menu — and go searching until they either find it or give up searching.

People who use alternative input methods may have difficulty locating and operating controls that display only on hover or focus. For example, speech recognition users activate controls by speaking the name of the control. Functions that are only exposed through hover interaction or keyboard focus can pose significant barriers to alternative input methods.

Information needed to identify controls does not need to be visible all the time. But information needed to identify controls must be visible when the controls are needed without hover interaction or keyboard focus. Controls can be available through a persistent visible entry point, such as a menu button that opens subitems. In a multi-step process or multi-part form, controls may be hidden in an earlier step or part; however, at the time the user can move the process forward, the information needed to identify the control, which is usually the control itself, must be visible without hover interaction or keyboard focus.

Ideally the information needed to identify controls exist would be visible all the time. Controls can be available through a persistent visible entry point, such as a menu button that opens subitems. There are also several exceptions outlined in the criterion text:

The exception for components that provide "keyboard-only functionality" is to allow for features such as skip links, which are not visible by default. As they appear on focus, and are aimed at keyboard-only users, they are not intended to be covered by this criterion.

Information needed to identify user interface components is usually the component itself; however, there are situations where controls are not visible. Complex components such as video players and carousels often include controls that are visible on hover. The presence of the complex component — for example, the carousel component or the video image — provides the “Information needed to identify the user interface components.” For a carousel, controls displayed on hover should also be displayed when the carousel is activated. For a video player, activating the video image should launch the video (sometimes in a new window), at which point more video player controls, including controls displayed previously on hover, should be visible. Some users may still struggle if video controls are not persistently visible, so there is benefit to providing a mechanism that allows users to have the controls persistently visible.

Many scenarios are out of scope because they do not rely on hover or focus, for example:




Other Success Criteria apply to the requirement for controls being “visible." Visibility is not limited to appearing graphically on the screen, but also includes following a meaningful sequence, not relying on sensory characteristics, and all other requirements under 1.4: Distinguishable.


Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

  1. G222: Provide persistently visible controls
  2. Indicate programmatically that a control is important (future)

Key Terms


if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

user interface component

a part of the content that is perceived by users as a single control for a distinct function


Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.


User interface components include form elements and links as well as components generated by scripts.


What is meant by "component" or "user interface component" here is also sometimes called "user interface element".

An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."