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


Every page of your website has a language assigned

Setting every webpage’s HTML language is an easy way to help your users, including those browsing your website with assistive technology. Setting a language is important because the way that screen readers pronounce words depends on the HTML language assigned to your website.

What to do

Ensure that each page of your website has a language assigned to it.


  • Set the language in your template and you’ll only need to do this once.
  • If you trade internationally and have different parts of your website in different languages, make sure they are assigned correctly.
  • HTML language codes match the ISO language codes standard. W3Schools has a full list of language codes.

See also

‘Link Purpose (In Context)’ requires that every link’s purpose is clear from its text or context.


It’s essential that you make your links clear and easy to understand, ideally from just the link text itself.
That’s because users with assistive technology, like a screen reader, often hear all the links on a page to help them find where they want to go. Others may view your website highly magnified or tab through links, so the user will only see the link text and a few words around it at any one time.

To help your users, your link text (the words that are linked, often called ‘anchor text’) must make the link destination clear, in the context of their surrounding content.

How to Pass ‘Link Purpose (In Context)’

Make sure that for each link on your website:

  • The purpose of the link is clear from the link text (for example, ‘My blog’); or
  • The purpose of the link is clear from the surrounding content, meaning the same sentence, paragraph or cell in a table (for example, ‘Visit my blog’); or
  • If the link is an image, the alt text of the image makes the link purpose clear (for example, ‘Luke McGrath – Visit my blog’); and
  • Links with the same destination have the same description (but links don’t share a description if they point to different places).


You don’t need to make the link purpose clear if the purpose is ambiguous to all  your users. 

For example, if I link the word ‘blog’ in the phrase ‘I have a personal blog’ the link might go to my blog, or it might go to a Wikipedia page explaining what a blog is. No user would reliably know where the link goes before they follow the link.

Of course, it’s best to avoid ambiguous links as users should always know where they are going. Although, there are times when you might want to spring a fun surprise on everyone.

‘Link Purpose (In Context)’ Tips

A good writer will only ever need the first option, making the link purpose clear for the link text. It is the most accessible solution and the best for your users. There is always a way to make your link accessible using link text alone. 

At Level AAA, Link Purpose (Link Only) requires you to make links accessible using only the link text.

Where you link to another page on your website, it’s good practice to use the page title you set in Page Titled as the link text.

See Also