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.
AA
New
Where receiving pointer hover or keyboard focus triggers user interface components to be visible, information needed to identify that user interface components are available is visible, except when:
- The information needed to identify the user interface components is available through an equivalent component that is visible on the same page or on a different step in a multi-step process without requiring pointer hover or keyboard focus;
- The component is provided specifically to enhance the experience for keyboard navigation;
- A mechanism is available to make the information persistently visible;
- Hiding the information needed to identify the component is essential.
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.
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 path forward.
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.
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 browser zoom. They may look closely at the monitor, say four inches from the display, due to limited acuity (inability to see detail) or Scotomas (blind spots). 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 to the point where they are looking. 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. This success criterion can help reduce that cumulative load.
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 pose significant barriers to alternative input methods, such as speech.
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.
In some cases, controls are provided in multiple locations on a page or at multiple points within a process. In these cases, at least one of the instances of the control must be visible without hover interaction or keyboard focus. For example, on an email listing page some controls such as trash may be visible using pointer hover in the inbox list view. However, those controls are always visible on the email page. Because the controls are persistently visible on the email view, they do not need to be persistently visible on the inbox view.
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.
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, being available through multiple sensory characteristics, and all other requirements under 1.4: Distinguishable.