When a keyboard user focuses on a control it must not cause a change of context, such as loading a new page/tab. This stops unexpected things happening without screen reader and screen magnifer users being aware of it.
Accessibility Requirements for 3.2.1 On Focus (A)
focusevents do not cause navigation, nor form submission
- components that respond to
focusdo not initiate a “focus trap”, where it is impossible or unclear how to navigate out of the component using the keyboard.
Common mistakes for 3.2.1 On Focus (A)
- Dropdown menus trigger navigation as the user tabs between options
- focus is moved by script in ways that surprise the user
The following are common mistakes that are considered failures of Success Criterion 3.2.1 by the WCAG Working Group.
FAQs for On Focus (A)
What to do to ensure website is On Focus?
1.Links don’t open automatically on focus; and
2.Forms don’t submit without the user taking action (such as clicking the ‘Submit’ button); and
3.There are no automatic pop-ups; and
4.Focus never jumps to another element automatically; and
4.No other action that occurs on focus alone causes the page to change.
What are the best practices for On Focus?
1.Ensure no element changes purely by receiving focus.
2.Avoid both behavioral and visual modifications.
What are the Exceptions?
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 isn’t a change of context.
Some examples of On Focus
Some examples of the changes that happen on focus are
Opening of a popup when user focuses on a link.
Opening of a sub-menu on focus.
Form is submitted when focused on a button.
Selecting an option in the dropdown and pressing escape or tab navigates to different page.
Help icon that opens automatically on focusing to a text field.