‘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 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


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. 


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.


  • 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. 


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.


  • 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.


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’.


  • 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

Clearly identify input errors

Everyone makes mistakes, even you and I. Make it easy for users to understand and correct their mistakes with a bit of guidance. Provide timely and clear error identification guidance when users make mistakes on your website. Using error identification keeps your website running smoothly and keeps your users from getting frustrated.

One of the worst areas for mistakes websites are forms, including checkouts, newsletter sign-ups and questionnaires. Any of your users can make a simple error that means they can’t submit your form. If users cannot identify their mistakes, they will leave.

What to do

  • Identify and explain to the user any mistakes that you can detect automatically.
  • Add error explanation close to the error, showing what is wrong and how to fix it.


  • If a form requires input in a certain format, show and describe the required format.
  • If a mandatory field is empty, highlight the field and explain what’s required.
  • Build forms to be forgiving, accepting variations on the formats you prefer.
  • Don’t ask for too much information, just what you need.
  • Be specific. Use clear, concise instruction and form field labels.
  • Highlight mistakes in forms with colours and symbols.
  • Don’t clear a form if a user makes a mistake. Save the information and allow the user to edit their error and continue.
  • Provide extra help by giving your contact details on all pages (the header or footer are great) and especially near forms.

See also

Elements do not change when they receive input

If you want your users to return to your website, make sure it acts as users expect it to.

When a form receives input from users (for example, typing in an address or selecting a date of birth), it must not automatically skip to another field or auto-submit – known as ‘changing on input’. This can disorientate users.

Only submit form data when a user chooses to click a submit button. It’s common sense behaviour, but if you get it wrong, your users will be frustrated and leave.

What to do

Here are some examples of the kinds of things to look out for:

  • Forms must not auto-submit when all fields are filled – this prevents your users from checking and editing what they have written.
  • Focus (the field where the user will input next) must not automatically jump to the next field in a form once a field is complete.
  • Using a control (like selecting yes or no) must not automatically perform the action (for example, selecting to subscribe to a newsletter in a check box must not automatically subscribe your user, they should be able to click a submit button to confirm their decision).


The easiest way to pass Guideline 3.2.2 is to use submit buttons and avoid jumping your users between fields. It’s all about leaving the control in your users’ hands, where it belongs.


Elements can change on input if you inform the user of the change before they have the chance to input their data or make their selection. For example, you may have seen websites with options in the header to choose a text size. Once you click on the size you want, the website changes without giving you the chance to confirm your choice.

Controls like that don’t need to have a submit button, as long as it’s clear from the text before the element what will happen when you input.

See also

Elements do not change when they receive focus

If your website doesn’t act as users expect it to, they’ll leave and you won’t see them again.

Focus is vital when considering what happens on your website when users reach elements like forms, videos and other interactive elements. Once an element receives focus from users, whether with a mouse or keyboard, the element must not automatically change (known as ‘changing on focus’). This can disorientate users.

A change of focus is especially troublesome for users who navigate by keyboard.

What to do

  • Ensure no element changes purely by receiving focus.
  • Avoid both behavioural and visual modifications.

Ensure that:

  • Links don’t open automatically on focus; and
  • Forms don’t submit without the user taking action (such as clicking the ‘Submit’ button); and
  • There are no automatic pop-ups; and
  • Focus never jumps to another element automatically; and
  • No other action that occurs on focus alone causes the page to change.


  • Most well-made websites will not have any of these errors by default, you would need to choose to add in change on focus.
  • A great way to test this guideline is to unplug your mouse and navigate your way round your website. If anything moves, submits or changes on focus, fix it!


Elements can change on focus if the context doesn’t change. For example, you can use a dynamic menu on your website, the kind where navigation options drop down when you hover over an item. This is not a change of context.

Another example would be a hover status on a link, again, this this isn’t a change of context.

See also