Definition for WCAG 2.0 success criterion 3.2.1
3.2.1 On Focus: When any component receives focus, it does not initiate a change of context.
The intent of this Success Criterion is to ensure that functionality is predictable as visitors navigate their way through a document. When a component (such as a form control - text input field, radio button/checkbox, <select> dropdown, button - or a link) receives focus, it must not trigger functionality that results in a change of context (e.g. loading a new page, immediately submitting the form, triggering an unexpected dialog and moving the user's focus to it, etc.).
Note: in general, components receive focus when navigating using the keyboard. Most focusable components also receive focus when clicked with the mouse (e.g. clicking on a text entry field or checkbox). However, clicking with the mouse will not only set focus, but also trigger any activation behavior on components such as buttons or links, and count as an "input" on certain controls such as checkboxes/radio buttons. If a change of context then happened as a result of activation or input, rather than focus, it does not violate this success criterion (though it may fail under 3.2.2 On input (level A)). To avoid confusion during testing, it is advisable to test this criterion by simply navigating / setting focus to components with the keyboard, leaving aside components which currently cannot be focused with the keyboard (and currently fail other success criteria such as 2.1.1 Keyboard (level A) and 2.4.3 Focus order (level A)) - with the exception of components which traditionally treat a click as neither an activation nor an input, such as <textarea> and any <input> elements which are generate a text entry field (such as <input type="text">, <input type="password">, <input type="date">).
Note: for success criteria involving keyboard testing, ensure that your browser/OS is set to allow for full keyboard navigation. In macOS in particular, go to System Preferences > Keyboard > Shortcuts and ensure that the "Full Keyboard Access" option is set to "All controls". If using Firefox/macOS, further ensure that the accessibility.tabfocus option in about:config is set correctly.
Note: if the page features no focusable components (i.e. the page only contains "content" without any interactive/operable elements), this criterion is marked as not applicable.
Testing success criterion 3.2.1
Input into spreadsheet
- Fail
- One or more focusable components triggered a change of context when they received focus.
- Pass
- None of the focusable components triggered a change of context when they received focus.
How to test
- Use keyboard navigation (TAB and SHIFT+TAB) to move focus through all focusable components of the page.
- For widgets/components with specific keyboard interactions (e.g. use of cursor keys to move focus between tabs in a tabbed navigation), use those specific keyboard interactions to move focus through those components.
- If the page features additional content such as modal dialogs, expand/collapse controls, etc., trigger these elements to reveal the content, then proceed as above using keyboard navigation to move focus through all focusable components that have been triggered/revealed.
- If the page features components such as text entry fields (e.g.
<textarea>or<input type="text">) which currently do not receive keyboard focus (a failure of other success criteria like 2.1.1 Keyboard (level A) and 2.4.3 Focus order (level A)), use the mouse to click on these components and attempt to set focus to them.