‘Visible Controls’ requires websites to give users a way to identify controls without mouse hover or keyboard focus.


Users with cognitive impairments, visual disabilities, mobility or motor issues may have difficulty using components if they are hidden until hovered over by a mouse pointer or focused on through keyboard navigation.

Controls that are hidden or displayed on

Visible Controls (Level AA – 3.2.7)Read more

‘Consistent Help’ requires that help and support options are presented in the same order.


Offering help options is great for all users, whether the help is human contact or self-service. Users with disabilities may use help options more than other users and will benefit from consistent presentation of their choices.

A simple way to achieve this is

Consistent Help (Level A – 3.2.6)Read more

The target size minimum for pointer inputs is at least 24 by 24 CSS pixels.


Users with mobility impairments may have difficulty using elements if their target area is small. These users may have trouble with aiming or being able to keep a pointer steady. Larger target areas help these users interact with controls and elements.


Target Size (Minimum) (2.5.8 – Level AA)Read more

Functionality that uses dragging movements can be achieved with a single pointer without dragging.


Some users with mobility impairments may have difficulty using a dragging action precisely, either by mouse pointer or touch. Others may use an accessibly input mechanism, such as eye control, that makes dragging even more difficult or even impossible. 

These users need an

Dragging Movements (2.5.7 – Level AA)Read more

‘Concurrent Input Mechanisms’ requires no restrictions on modes of input.


Users may choose to switch between different methods of input when interacting with a website. For example, for some controls a user might prefer to input by keyboard and for others they might favour a mouse.

Users might also prefer to override the primary input mechanism for

Concurrent Input Mechanisms (2.5.6 – Level AAA)Read more

Motion Actuation requires that functions operated by motion can also be operated through an interface and responding to motion can be disabled.


Where gestures such as pointing or movements like a shaking or tilting control a function, some users will need to be able to control these through a more standard interface. Users with mobility impairments

Motion Actuation (2.5.4 – Level A)Read more

“Label in Name’ requires that where a component has a text label, the name of the component also contains the text displayed.


Some users rely on the programmatic names of components and controls, rather than text that is visually displayed on them. This is especially useful for users relying on assistive technology such as screen readers

Label in Name (2.5.3 – Level A)Read more

Pointer Cancellation requires that functions don’t complete on the down-click of a pointer.


Some users may need extra help using a mouse or prefer to use assistive technology in place of a mouse. It’s important to reduce the chances of an accidental click for these users by ensuring that the down-click of a mouse pointer alone

Pointer Cancellation (2.5.2 – Level A)Read more

‘Pointer gestures’ requires that multi-point and path-based gestures can be operated with a single pointer.


Some users cannot easily perform gestures in a reliable or precise way, which can make it difficult for them to interact with websites where gestures are required. To overcome this, users might have assistive technology driven by speech or eye movement

Pointer Gestures (2.5.1 – Level A)Read more