Skip to main content

Tagged as

Operable

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 seperate interpretation. Stay tuned.

Tips for developers: Get your website teted for accessibility – Part 2 – Operable

This is Part 2 of 4 parts on how a developer should get their website or application tested for accessibility. Objective of this series is to provide easy method of accessibility testing to developers so that they can test as they code. This is how we would achive accessibility right at the development and design stage. These tips would not only be helpful to developers but also to interaction designers who decides interaction of elements and those who develop prototypes. This Part 2 is related to Operable section of Web Content Accessibility Guidelines 2.1.

Question: How to test for keyboard accessibility?
Answer: Load the page. Press CTRL + Home (Windows), this will take focus to the top of the page. Then use tab key to move from one element to another. Use enter or space key to activate an element. One should be able to activity every element including menus, modals, buttons etc.,

Question: When I was browsing a page with keyboard, focus does not move from an element, focus just gets stuck; is there a problem with my keyboard?
Answer: Probably not, this is called keyboard trap and needs to be avoided. When a component recieves keyboard focus, there should be mechanism to move away keyboard focus from same component.

Question: What to consider when there is a time limit for a page?
Answer: Check if there is an option to turn-off timing, adjust as per user’s requirement or extend the time limit. There could exceptions such as activity at real-time, esential time limit such as a test and time limit of 20 hours and more.

Question: What to look for elements that moves, blinks or scroll?
Answer: There should be a mechanism to pause, stop or hide. If content is being updated automatically, there should be a mechanism to pause or set how periodical that an update should happen.

Question: What is bypass blocks and how do we test?
Answer: Bypass blocks is a mechanism to enable keyboard users to skip representative set of blocks such as navigation and jump quickly to main content. This can be achieved by providing “Skip to main content” link at the top, using appropriate heading structure and/or using ARIA land marks.

Question: How to test page titles?
Answer: Look at top bar of browser window and see if page title does exist and is appropriate. For example Page title should be page name along with the company / domain name. It should not be just company name only on all the pages.

Question: What all needs to be considered as Focus order issues?
Answer: Ensure that the tab order is logical, if an element opens a modal, focus focus must be set to modal and must not move out until user closes the modal, When modal is closed, focus should be returned to the triggered element.

Question: Testing for link purpose
Answer: Ensure that all links have meaningful and spell out the context to the users. Avoid links like “Read more”, “Click here” etc., Using automated tools would be effective to test this requirement.

Question: What are the multiple ways required for a website?
Answer: A search functionality or a site map. There should be more than one way to reach a specific page on the website.

Question: How to test for focus visible?
Answer: When you tab through the page, every element should receive an indicator and you should be able to see where the keyboard focus is. It can be either custom focus indicator or browser’s default focus indicator.