Updated Web Accessibility Checklist – Operable

This is 2 of 4 in our series to put together an updated web accessibility checklist. As mentioned in our earlier post Updated Web Accessibility Checklist – Perceivable, this post may get updated once Web Content Accessibility Guidelines (WCAG) 2.1 becomes candid recommendation. (Reminder: last working draft is out; have your say soon!).

In this post, we will discuss what to check for operability of the web.

Ensure that content doesn’t flashes more than three times in one second or below the general and red flash thresholds

Level	WCAG 2.1 Success Criterion	What to check for?
A	2.1.1 Keyboard	Ensure that functionality is operable using keyboard; including but not limited to input fields, links, buttons, menus, controls, etc.,
A	2.1.2 No keyboard trap	Ensure that there is no keyboard trap. If users gets focused on an element using keyboard, they should be able to move out of the same component with the keyboard interface.
A	2.2.1 Timing Adjustable	Ensure that user is alerted about session time-out and there is a mechanism to extend the session time. except where session time-out is essential such as for a test etc., In such a case, user should be notified and alerted.
A	2.2.2 Pause, stop, hide	For blinking and moving content that starts automatically and plays for more than 5 seconds, provide a mechanism for user to pause, stop or hide. For auto-update of content, allow user to pause, stop, hide or change frequency of update.
A	2.2.6 Accessible Authentication	Ensure that authentication process itself is accessible. This is a new SC in WCAG 2.1 – more interpretations will be available soon
AA	2.2.7 Interruptions (Minimum)	Ensure there is an easy mechanism is available to postpone or suppress interruptions. Unless they are initiated by the user. This is also a new SC in WCAG 2.1
A	2.3.1 Three flashes or below thresholds
A	2.4.1 Bypass blocks	Use any of the following methods to help users (specially keyboard only and screen reader) to bypass repeated blocks of content such as navigation. Provide Skip to main content link. This needs to be the first link on the page. This can be visible or made visible on focus Use appropriate heading structure using <heading> mark-up Use ARIA landmark roles
A	2.4.2 Page titled	Ensure every page has a descriptive and unique title. This should describe purpose or topic of the page
A	2.4.3 Focus order	Ensure tab order is meaningful for focusable elements When activating an element opens a modal, ensure that keyboard focus is placed on the modal When user is navigating within a modal, ensure that focus does not shift away from the modal until user closes modal When user closes modal, ensure focus returns to the triggered element
A	2.4.4 Link Purpose	Ensure that context of link is available with link text alone. Avoid use of link text like Read more, click here etc., if used, ensure to provide descriptive information using techniques like <aria-describedby> or using <off-screen> text.
AA	2.4.5 Multiple ways	Ensure that there are more than one way to find content on the website. Some of the techniques could be use of Site search, Site map etc.,
AA	2.4.6 Headings & Labels	Ensure that all sections or topics have headings using <heading> attribute. This is helpful even when a form has multiple sections Ensure input fields have visible labels. Placeholders are not a great way to do unless a mechanism is implemented in a way that labels are always visible even after entering data into input field. Exception is short and usual forms such as Search form, login form.
AA	2.4.7 Focus visible	Ensure focus indicator is visible on all focusable elements. Do not override focus indicator using <outline:none>. If you do not like browser’s native focus indicator, be sure to code a customer focus indicator such as using <outline:dotted>
A	2.4.11 Character key shortcuts	If there is a key shortcut that require use of multiple key combinations, provide a mechanism to either turn off or map with another key combination of user’s convenience. This is a new SC
A	2.4.12 Label in name	When user interface component has additional text with label, that text should be presented with the accessible name.

In WCAG 2.1, Sections 2.5 Pointer accessible and 2.6 Additional sensor input are newly introduced and we will do these sections as a separate interpretation. Stay tuned.