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 shake or a tilt 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

‘Page Break Navigation’ requires you to provide a way to navigate between page break locators.

Page break locators are a way to guide users through meaningful points within content. For example, an online version of a book might use page markers to match up with a print edition. 

Users with visual impairments or those who rely on digital means to consumer content can use page break locators to find a certain point within the text. For example, if a teacher asks them to read pages 34 – 59 before the next lesson. 

How to Pass ‘Page Break Navigation’

If your content has page break locators, provide users with a way to navigate to and between them:

  • In HTML you can add page list navigation using <nav role=”doc-pagelist”>
  • You could then add designations using <span id=”pg1”>

‘Page Break Navigation’ Tips

This only applies when you have content with page break locators, it’s not a requirement to add these to your content.

See Also

Allow users to turn off or remap single-key character shortcuts. 

Introduction

Keyboard shortcuts can help some users, but cause difficulty for those using speech input and some users with motor impairments. They can also cause issues on mobile screens as the functional area is reduced on a mobile keyboard.

For speech input users, single-key character shortcuts (for example, the letter key “F” for starting a search) are particularly bad as a spoken word can be interpreted as several individual keystrokes. 

The best course of action is to avoid using single-key character shortcuts.

How to Pass ‘Character Key Shortcuts’

  • Don’t use single-key character shortcuts
  • If you really want to:
    • give users a way to turn off the shortcut;
    • allow users to remap the shortcut to use non-character keys; or
    • ensure the shortcut only works when an element has focus.

Exceptions

  • Shortcuts where one key is not a character (for example ‘alt’ or ‘alt’ + ‘c’)
  • Elements where the shortcut is only active on focus (for example, lists and dropdown menus).

‘Character Key Shortcuts’ Tips

One last time, please just avoid setting up single-key character shortcuts.

Characters include letters, numbers, punctuation and symbols – anything you could type into a word processor and print off.

See Also

Keyboard focus is visible when used. 

Introduction

Where there are multiple elements on a webpage, it helps users to highlight which element has keyboard focus. This helps users who rely on a keyboard to navigate as it shows them which element the keyboard will interact with. Users with attention or short-term memory limitations will also benefit from a visual cue to where focus is located.

How to Pass ‘Focus Visible’

When an element has keyboard focus, show a visual indication.

‘Focus Visible’ Tips

For form fields, you might display a bar within the field or highlight the entire field.

For controls, you might display a border around the control.

See Also

Build all elements for accessibility

Everything that’s on your website needs to work to defined standards. Where you’re writing code that’s not HTML, it must conform to HTML-like standards. This means that it will work with various assistive technologies.

The key things to consider are advertising widgets, forms from third parties, things you’ve coded yourself and anything that you add that you can’t be sure how it was coded.

What to do

  • Use HTML specifications for any script you author for your website.
  • If you use a plugin or other element authored by a third party, make sure it uses valid HTML markup.

Tips

  • A good – though not foolproof – way to test your website is a HTML validator tool. A validator gives you an idea of how well technology can parse your website. Use it to create a list of priorities.
  • The majority of your potential issues will come from third-party code.
  • Speak to the developers of any plugins you use and make sure that they’re writing good code.
  • Make sure that everything on your website parses correctly.
  • Pay close attention to things like names and labels.

See also

Your website has no major code errors

Parsing is the way software like web browsers and assistive technology read and understand a website. It’s important that the different technologies your users use to view your website don’t have trouble parsing your website. Parsing is all about your website’s code.

All your users will benefit from a website built on clean and modern HTML. Your website will work properly in all web browsers and on all kinds of devices, from computers to tablets to smartphones.

Your users who rely on assistive technology will benefit from a well-made website as the technology often relies on HTML parsing. Bad or broken HTML is more likely to cause parsing problems for assistive technology and so increase the chance of users leaving your website.

What to do

This is a wide-ranging guideline, one that changes with time as standards evolve. Your best protection is hiring a web designer who knows parsing well. Find one through recommendations and ask them about their approach to web standards and accessibility.

Here are the most common issues to watch out for:

  • Ensure HTML elements have complete start ( < > ) and end ( </ > ) tags where needed.
  • Nest all HTML elements correctly (for example, list objects within an ordered or unordered list).
  • Use unique Ids.
  • Check that HTML elements don’t contain duplicate attributes.

Tips

A good – though not foolproof – way to test your website is a HTML validator tool. A validator gives you an idea of how well technology can parse your website. Use it to create a list of priorities.

See also

Label elements and give instructions

Chances are your website will have a feature that requires your users to fill in some information. This might be on a checkout page to buy a product, a contact form to get in touch or a newsletter sign-up to opt in to your mailing list. You need to ensure your users know what’s required of them when they reach one of these elements on your website.

Without clear labels and instructions, your users won’t know what to do.

What to do

  • Label all input fields clearly and helpfully.
  • Where a field needs a specific format, give an example (For example, for a ‘date’ field in a form you might use ‘Enter the date as dd/mm/yyyy’)
  • Mark required fields with an icon and explain what the icon means before the form.
  • Keep your labels simple – too much explanation can be counter-productive. Things like ‘First name’, ‘Email’ and ‘Your message’ are fine.
  • The same goes for instructions, ‘Required fields are in red and have a * symbol’ works great. So does ‘Fill in this form and click ‘Submit’ to get in touch’.

Tips

  • Instructions need to take into account how they use sensory characteristics.
  • Think about how your use of colour affects things like required fields if you want to highlight them by colour. Don’t highlight by colour alone, pick a symbol too.
  • Consider error identification as well, and make sure that you give helpful instructions when your users make mistakes on forms.

See also