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

Introduction

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.

How to Pass ‘Target Size (Minimum)’

Ensure that the target areas for all pointer inputs are at least 24 by 24 CSS pixels.

Exceptions

  • When there is at least 24 CSS pixels distance to any adjacent target.
  • When the target is a sentence or block of inline text.
  • When the presentation of a target that doesn’t meet the requirements is essential.

‘Target Size (Minimum) Tips

Making the spacing of targets at least 44 by 44 CSS pixels will pass 2.5.5 – Target Size at Level AAA.

Remember that pointers include both mouse control and touch control.

Although there is a minimum size, the larger the control the easier it is for everyone to use.

Consider making frequently used or important controls larger.

Be careful not to place controls near the edge of a screen as this may be more difficult to reach for some users.

See Also

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

Introduction

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 alternative that enables them to complete the same input as dragging.

How to Pass ‘Dragging Movements’

Where a control uses dragging, provide an alternative.

Exceptions

Where dragging is essential. For example, creating art or playing a game where dragging is a design feature.

‘Dragging Movements’ Tips

A dragging movement is one where only the start and end points matter, the direction between them is not considered. 

A common example of a dragging control is one where the user drags elements into a certain order. This can also be achieved by a clickable up/down navigation or by typing numbered values next to elements.

See Also

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

Introduction

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 a device. For example, connecting an external keyboard to a touchscreen tablet. Allowing users to switch between concurrent input mechanisms can satisfy these needs.

How to Pass ‘Concurrent Input Mechanisms’

Ensure there are no restrictions on modes of input. 

Exceptions to ‘Concurrent Input Mechanisms’

  • Where a set input mode is essential. For example, a touch-typing test.
  • If the restriction is required for security.
  • If the restriction is required to respect a user’s setting.

See Also

Understanding Success Criterion 2.5.6 (W3C)

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

Introduction

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.

How to Pass ‘ Target Size’

Ensure that the target areas for all pointer inputs are at least 44 by 44 CSS pixels.

Exceptions

  • When the target is available through an equivalent control on the same page that meets the requirements.
  • When the target is a sentence or block of inline text.
  • When the target size is controlled by the user agent.
  • When the presentation of a target that doesn’t meet the requirements is essential.

‘Target Size’ Tips

Remember that pointers include both mouse control and touch control.

Although there is a minimum size, the larger the control the easier it is for everyone to use.

Consider making frequently used or important controls larger.

Be careful not to place controls near the edge of a screen as this may be more difficult to reach for some users.

See Also

Understanding Success Criterion 2.5.5 (W3C)

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

Introduction

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 may not be able to make the correct movements (or make them precisely) enough to interact with these types of controls.

Similarly, some users may inadvertently use these controls and therefore need a way to switch them off.

How to Pass ‘Motion Actuation’

  • Ensure users can enable and disable gesture and movement-based controls.
  • Provide a standard interface (such as a button) in addition to motion and gesture controls.

Exceptions

  • Where the motion operates a function through an accessible interface supported by the user’s assistive technology and:
    • The technology is supported widely (such as HTML); or
    • The technology is supported in a widely distributed plug-in; or
    • The content is within a closed environment or network where the user agent required is accessible; or
    • The user agents that support the technology are available at the same cost and as easily to users with and without disabilities. 
  • Where the motion is essential for the function, for example a step counter that uses movement to calculate distance. 

‘Motion Actuation’ Tips

Ignore the exceptions and stick to providing alternate interface and the ability to disable motion controls.

See Also

Understanding Success Criterion 2.5.4 (W3C)

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

Introduction

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 as the name of the control and the text displayed on it will match.

For speech-input users, mismatched labels and names may present them from effectively interacting with a control as they will need to use a name different to that displayed.

How to Pass ‘Label in Name’

  • Ensure that the text label and programmatic name of components match.
  • Abort actions where the pointer is released outside the boundary of the target.

Exceptions

  • Where there is no visible label for a component. 
  • Where text is used symbolically, for example ‘ABC” used to indicate a spellchecker.

‘Label in Name’ Tips

  • Labels include:
    • Text to the left of dropdown lists and text inputs
    • Text to the right of checkboxes and radio buttons
    • Text inside buttons and tabs
    • Text below icons used as buttons
  • Programmatic names include alt text, aria-label and aria-labelledby attributes.
  • Programmatic names can be simplified versions of the display text if they begin with the same word. For example, ‘Search this page’ could use a name of ‘Search’.
  • When deciding how much text counts as a visual label, take a commonsense approach. The text immediately adjacent to the control will be enough.

See Also

Understanding Success Criterion 2.5.3 (W3C)

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

Introduction

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 doesn’t complete a function.

How to Pass ‘Pointer Cancellation’

  • Ensure that actions are only taken when a pointer is clicked and released within the boundary of the target.
  • Abort actions where the pointer is released outside the boundary of the target.

Exceptions to ‘Pointer Cancellation’

Where it’s essential the action occurs on the down-click. 

This might seem rare but is relevant to keyboard emulators, where a letter appears typed on the down-press of a key (and therefore the down-press of a mouse in an emulator. A music keyboard or shooting game may also need the action to complete on the down-click. In these instances there are often other ways for users to change an action that don’t need pointer cancellation.

See Also

Understanding Success Criteria 2.5.2 (W3C)

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

Introduction

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 to make gestures.

Multi-point or path-based movements can be particularly challenging for some users. A multi-point gesture is one where two or more gestures are needed together. For example, a two-finger pinch and zoom or swipe. A path-based movement might be drawing a shape or swiping through a carousel.

How to Pass ‘Pointer Gestures’

Where you have a function that requires a multi-point or path-based gesture, provide a way for a user to operate the same function with a single pointer.

For example:

  • Where a map might use pinch and zoom it can also have + and – controls operated by a single click or tap.
     
  • A carousel operated by a series of swipes can also have ‘forward’ and ‘back’ buttons

Exceptions

Where a multi-point or path-based gesture is essential for functionality. For example, drawing a signature on a document.

‘Pointer Gestures’ Tips

This goes beyond providing a keyboard accessible control as some users find pointers easier to use than keyboards. A user with an eye movement pointer will often find it easier to point at a control than to switch to a keyboard.

See Also