Keyboard only (2.1.1): All content and functions on a website must be accessible by keyboard only (i.e. no mouse).
No keyboard trap (2.1.2): Keyboard-only users must never get stuck on any part of the website; they must be able to navigate forwards and backwards.
2.1Keyboard shortcuts (2.1.4): If you have a keyboard shortcut, make sure a user can either 1) turn it off, 2) there’s a way to add another key in the shortcut, and/or 3) have the shortcut only active while focusing on a specific component.
Adjustable time (2.2.1): If there any time limits on a website, users have the ability to turn it off, adjust it, extend it.
Pause, stop, hide (2.2.2): If there is content that blinks, scrolls, moves, users must have the ability to pause, stop, or hide it.
Focus indicator (2.4.7): Any “user interface control” that receives focus from a keyboard user should indicate that focus on the current selected element (e.g. add a visible border around a text link).
2.1Pointer gestures (2.5.1): Provide simple alternatives (e.g. single tap vs. swipe) to potentially complex finger motions on touch screens.
Consistent identification (3.2.4): Components that have the same function within a website are identified consistently (but not necessarily identically) (e.g. two check marks can indicate two different things as long as their function is different — one indicates “approved” on one page but “included” on another).
Error suggestions (3.3.3): If an input error is automatically detected, then suggestions for correcting the error should be provided.
Error prevention on important forms (3.3.4): For pages that create legal commitments or financial transactions or any other important data submissions, one of the following is true: 1) submissions are reversible, 2) the user has an opportunity to correct errors, and 3) confirmation is available that allows an opportunity to review and correct before submission.
Parsing (4.1.1): Make sure HTML code is clean and free of errors, particularly missing bracket closes. Also, make sure all HTML elements are properly nested.
Name, role, value (4.1.2): For all user interface components (including forms, links, components generated by scripts), the name, role, and value should all be able to be programmatically determined; make sure components are compatible with assistive technology.
2.1Status Messages (4.1.3): When a status message appears, it should be coded with role or properties so that people using assistive technologies (e.g. screen readers) are alerted without losing focus.