Skip to main content


Tagged as

WCAG 2.1

New Success Criterion in WCAG 2.1: 2.5.1 Pointer Gestures (Level A)

Success Criterion 2.5.1: 2.5.1 Pointer Gestures (Level A): All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

With increase in touch devices, method of pointer gestures have become quite common. It has also become popular when users can use diverse range of gestures. 

Let’s take an example of a news app; by use of pinch, user can zoom in and zoom out the text. However, when user does not have ability to pinch, there should be alternate method of achieving the same functionality. Perhaps by using Zoom-in and Zoom-out buttons or with an option in app settings. 

That said, this success criterion does not to apply to functionality provided for the operating systems – such as swiping down to bring notification menu or functionality provided in assistive technologies; such as talk back (screen reader on Android) has its own gestures for ease of use. 

Another exception is where path based gesture is a mandatory such as drawing a signature. 

How to test?

Identify if a functionality requires use of path based gesture such as swiping, dragging or drawing. One of the examples would be “Place an order” element on Amazon app where user requires to swipe from left to right to complete the order. Another example would be zoom-in or zoom-out on maps. 

Web Content Accessibility Guidelines (WCAG) 2.1 is now official


New Support in WCAG 2.1



Read the complete blog post by Andrew and Micheal on W3C Blog

Here are list of New Success Criterions in WCAG 2.1

Guideline 1.3 Adaptable


1.3.4 Orientation (Level AA)


Comic with cerebral palsy who uses a wheelchair:


Understanding Orientation

1.3.5 Identify Input Purpose (AA)


Supermarket assistant with dyslexia and dyscalculia:

    Note: This works because the fields use autocomplete.

Understanding Identify Input Purpose

1.3.6 Identify Purpose (AAA)


Gamer with language processing disability:

  • Works well:It works pretty good with some websites.

Understanding Identify Purpose

Guideline 1.4 Distinguishable


1.4.10 Reflow (AA)




Parent with low vision – 20/400:


Understanding Reflow

1.4.11 Non-Text Contrast (AA)


User Interface Components
Graphical Objects

Retiree with low contrast sensitivity:


Understanding Non-text Contrast

1.4.12 Text Spacing (AA)


  • Word spacing to at least 0.16 times the font size.


Student with dyslexia:
and Retiree with low vision:


Understanding Text Spacing

1.4.13 Content on Hover or Focus (AA)




Teacher with low vision who uses screen magnification software:


Understanding Content on Hover or Focus

Guideline 2.1 Keyboard Accessible

Make all functionality available from a keyboard.

2.1.4 Character Key Shortcuts (A)


Turn off
mechanism is available to turn the shortcut off;
Active only on focus

Reporter with repetitive stress injury who uses voice recognition software:


Understanding Character Key Shortcuts

Guideline 2.2 Enough Time

Provide users enough time to read and use content.

2.2.6 Timeouts (AAA)


School playground aide with cognitive disabilities:


Understanding Timeouts

Guideline 2.3 Seizures and Physical Reactions


2.3.3 Animation from Interactions (AAA)


Artist with vestibular disorder:


Understanding Animation from Interactions

Guideline 2.5 Input Modalities


2.5.1 Pointer Gestures (A)


Comic with cerebral palsy who has limited movement in fingers:


Understanding Pointer Gestures

2.5.2 Pointer Cancellation (A)


No Down-Event
Abort or Undo
Up Reversal
Completing the function on the down-event is essential.

Politician with motor disabilities and low vision:


Understanding Pointer Cancellation

2.5.3 Label in Name (A)


Reporter with repetitive stress injury who uses voice recognition software:


Understanding Label in Name

2.5.4 Motion Actuation (A)


Supported Interface

Comic with cerebral palsy who uses a wheelchair:


Understanding Motion Actuation

2.5.5 Target Size (AAA)


The target is in a sentence or block of text;
User Agent Control

Retiree with hand tremor (and big fingers):


Understanding Target Size

2.5.6 Concurrent Input Mechanisms (AAA)


Reporter with repetitive stress injury who uses voice recognition software:


Understanding Concurrent Input Mechanisms

Guideline 4.1 Compatible


4.1.3 Status Messages (AA)


Accountant who is blind and uses a screen reader:


Understanding Status Messages



Gratitude to everyone involved in building these standards.

WCAG 2.1 is now a proposed recommendation


7.6.4 Call for Review of Proposed Corrections



  1. specify the deadline for review comments;
  3. solicit public review.




Ongoing work: Same as for a Proposed Edited Recommendation.




WCAG 2.1 is now a candid recommendation

Accessibility Guidelines Working Group of W3C has published WCAG 2.1 as a candid recommendation (CR). Purpose of CR is to ensure that standard can be implemented. Results of this exercise will be made available on WCAG 2.1 Implementation report once it’s completed. Working group plans to complete this by June 2018.

What’s new in WCAG 2.1

Addresses more accessibility requirements of people with cognitive disabilities, people with low vision and improves accessibility of mobile. Features of WCAG 2.1 are:

WCAG 2.1 extends WCAG 2.0 by adding new success criteria, definitions to support them, guidelines to organize the additions, and a couple of additions to the conformance section. This additive approach helps to make it clear that sites which conform to WCAG 2.1 also conform to WCAG 2.0, thereby meeting conformance obligations that are specific to WCAG 2.0. The Accessibility Guidelines Working Group recommends that sites adopt WCAG 2.1 as their new conformance target, even if formal obligations mention WCAG 2.0, to provide improved accessibility and to anticipate future policy changes.

The following Success Criteria are new in WCAG 2.1:

Many of these success criteria reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.

In the Conformance section, a third note about page variants has been added to Full Pages, and an option for machine-readable metadata added to Optional Components of a Conformance Claim.

What we should do

Apply WCAG 2.1 to our day-to-day work and report when a success criterion cannot be implemented. Do file an issue on Github or write to Chairs of Accessibility Guidelines Working Group.

Let’s do some exiting work! Sincere thanks to everyone involved in building accessibility standards.

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.

Last chance to comment: WCAG 2.1 last public working draft is now available

The Accessibility Guidelines Working Group of W3C has published last public working draft of WCAG 2.1 and one can send in comments no later than 12th January, 2018. This is a fantastic opportunity for those who are not full time into accessibility but want to spend their holiday / festive session in getting acquitted with something new. A quick note from Editors of WCAG 2.1

WCAG 2.1 adds new success crtiteria to expand coverage users of mobile devices, people with cognitive or learning disabilities, and people with low vision. Most success criteria are complete, but some are still under discussion. The success criteria under discussion are marked with editorial notes and pointers to the ongoing discussion. As these success criteria are finalized, they will be updated in the Editors’ Draft

Because this is the final Working Draft, we encourage you to comment on all success criteria as soon as possible, and please comment no later than 12 January 2018. If you have comments on this draft or on continuing work on open issues, we prefer that you file input as new issues in GitHub

Alternatively, you can send email to:

The Working Group plans to publish the Candidate Recommendation in late January 2018. The Candidate Recommendation will include the final form of success criteria currently still under discussion, though they will be marked as “at risk” due to the lack of review opportunity from this current draft.

Additional background on WCAG 2.1 is available from previous announcements:

More information about the Accessibility Guidelines Working Group is available from its home page

So here is a final chance to have your say in building standards to create inclusive web experiences!

Updated Web Accessibility Checklist – Perceivable

Back in 2010, we have published a Quick Web Accessibility Checklist that received a good response and we have also received a good feedback. It’s true that users prefer to have a quick checklist along with large documentation to achieve their accessibility mission. So we are bringing you this updated Web Accessibility Checklist reflecting success criterions of Web Content Accessibility Guidelines (WCAG) 2.1.  Please note this checklist gets updated once again when WCAG 2.1 becomes a W3C recommendation (expected to be in 2018). Also, note that all external links on this page opens in a new window. We will be publishing this as a series of 4 posts so that it will be easy for users to refer.

Level WCAG 2.1 Success Criterion What to check for?
A 1.1.1 Non-text content
  •  All active images do have appropriate alternate text
  • All informative images do have appropriate alternate text
  • All decorative images are provided with null <alt> attribute.
  • Ensure that no informative images are used as background images. All informative images need to be in foreground and have appropriate alternate text
A 1.2.1 Audio-only and video-only (prerecorded)
  • For pre-recorded audio-only content, ensure to provide a text transcript
  • For pre-recorded video only content, ensure to provide an audio track
A 1.2.2 Captions (prerecorded) Ensure that captions are provided for all audio based content except where audio description is alternative to visual content
A 1.2.3 Audio description or media alternative (prerecorded) Ensure that audio description is provided for all prerecorded video content except where video itself is alternative to audio content
AA 1.2.4 Captions (Live) Ensure that captions are provided for live video content in synchronised manner
AA 1.2.5 Audio description (prerecorded) Ensure that audio description is provided for all prerecorded video content in synchronised media
A 1.3.1 Info & relationships
  • Has the page marked-up using semantics?
  • Page must have one first level heading using <h1>
  • Is the heading structure on the page appropriate?
  • If any content appears as a list, has it marked up using <list> attribute?
  • Has form labels associated with their input fields?
  • Are radio buttons / checkboxes associated with their group label?
  • For data tables, are data cells associated with their row / column headers?
  • Is CSS used to control the layout than using <table> mark-up?
A 1.3.2 Meaningful sequence Is the reading order meaningful from its presentation?
A 1.3.3 Sensory Characteristics Ensure that no instructions are provided in way that requires use of a specific sense of users such as using shape, color, visual location, size, orientation or sound
AA 1.3.4 Purpose of control This is a new Success Criterion and needs some interpretation to understand. This talks about personalisation of controls. While icons for different purpose may have standard icons, it’s recommended that user should be able personalise it.
A 1.4.1 Use of Colour Do not use colour as a sole means of information. Example: Normally “green” is shown to indicate success and “red” to indicate failure. While showing the same in color, it is also important to show as “text”.
A 1.4.2 Audio-control
  • Check if page any audio that plays automatically for more than 3 seconds
  • If yes, ensure that there is a mechanism to pause / stop or ability to control the volume using system’s volume control
AA 1.4.3 Contrast – Minimum Ensure that there is minimum contrast ratio of 4.5:1 for regular text between foreground and background. For large text, minimum contrast ratio should be 3:1. Incidental text such as inactive controls and logotypes do not require to have minimum ratio of contrast.
AA 1.4.4 Resize Text Ensure that user should be able to zoom in content upto 200% without use of any assistive technologies. This is not applicable for captions and images of text
AA 1.4.5 Images of text Use natural text to provide information unless it’s essential to embed text to an image. Logotype is known as essential

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.

Tip for Developers: Get your website tested for accessibility -Part 1 Perceivable

Quite often, I receive emails from non-profit organizations asking if I can help them with accessibility testing for their newly built website. I also see most of them do not get built accessibility in mind though many of them are for organizations who offer services to people with disabilities. This post illustrate a few tips that developers can use while building a website. While we intend to see many developers have knowledge on accessibility, it’s absolutely fine to start with a willingness to build an accessible product. This post illustrates advice in the form of question and answer in reference to Web Content Accessibility Guidelines (WCAG) 2.1. This will be series of four articles to cover Perceivable, Operable, Understandable and Robust.

Question: Do you have images or any other non-text content?
Answer: When you have images, identify if they are informative images decorative images. If informative images, provide an alternate text. For decorative images, provide empty alt text i.e. alt=””; alt attribute must be present in any form of image; if not provided, path of the image gets exposed to assistive technologies such as screen reader, shown on text only browsers (or when images are turned off in the browser), shown to search engines.

Question: Do you have audio-only conent on the website?
Answer: Provide synchronized captions or text transcript

Do you have video only content?
Answer: Provide audio-description

Do you have a live audio / video event happening?
Answer: Ensure there is voice over when only visual actions are happening and captions are provided for audio. This will aid visually impaired users to know what’s visual actions are happening and hearing impaired users to know what the conversation is happening. If there is only music being played, show captions as “Music being played” and if possible what instrument is being played and some illustration.

Question: How my content should be structured and organized?
Answer: Ensure content is structured in a logical order, Headings are marked up appropriately using Hx values e.g. h1, h2 etc., Do not just decorate content as a heading, mark-up list items as ordered or unordered list, ensure all form fields do have associated labels using “for” and “id” attributes, radio buttons and check boxes have associated with their group label.

Question: My user tells me that my content is not read in right sequence, what could be wrong?
Answer: When content is presented in a sequence that is different than usual, it’s essential to ensure sequence of content is meaningful programmatically.

Question: Can I color code the information?
Answer: Yes, color can be used to convey information but color must not be the only form of presenting information. Example, accept is marked as “green” button and decline is marked as “red button”, same labels i.e. accept / decline must be provided as a text in addition to color code.

Question: Can I play audio or music automatically on my web page?
Answer: It’s a not a good practice to play audio automatically on a web page; reason being it would disrupt users with screen readers and people who do not expect an audio on loading of a web page. However, if audio has to played automatically and length is more than 3 seconds, controls must be provided to pause or stop the audio.

Question: How can I check for contrast of colors?
Answer: Simple way is to use Color Contrast Analyzer tools. See the list on Accessibility Testing tools section of Our Resources page

Question: How to meet resize text requirement?
Answer: User browser’s default zoom option (mostly CTRL and +) and zoom up to 200%

Question: Can I use images of text?
Answer: Where possible, it’s advisable to use text to convey the information rather than embedding onto an image.

Question: What’s graphics contrast?
Answer: It’s a new Success Criterion – 1.4.12 Graphics Contrast of WCAG 2.1. If information is conveyed only in the form of graphic e.g. charts etc., it must have minimum contrast ratio of 4.5:1.

Web Content Accessibility Guidelines (WCAG) 2.1 First Public Working Draft has been published – have your say!

It was in 2008, Web Accessibility Initiative Group of W3C has announced Web Content Accessibility Guidelines (WCAG) 2.0 as a candid recommendation. Since then, there has beena lot of of improvements and changes in technologies.

For more than a year now, Accessibility Guidelines Working Group have been working hard to introduce extended version of WCAG 2.0; as part of this effort, task forces have formed to work on needs of mobile, cognitive and low vision users.

Yesterday, Working Group has published Web Content Accessibility Guidelines 2.1 First Public Working Draft to see feedback from users across the world.

There are 28 new success criterias in WCAG 2.1; in which 3 have been formally approved by the working group; others are in proposed states. Three new success criterias that got accepted are:

  • Resize content
  • Graphics Contrast
  • Interruptions (minimum)

For this publication, Accessibility Working Group of W3C seeks feedback on following questions:

  • Do the new and proposed Success Criteria address current user needs for web content accessibility?
  • Does conformance to the new and proposed Success Criteria seem achievable and testable?
  • How well do the new and proposed Success Criteria fit with the existing Success Criteria from WCAG 2.0?
  • How completely does the set of new and proposed Success Criteria address current user needs, particularly for users of touch- and small-screen mobile devices, users with low vision, or users with cognitive or learning disabilities?
  • Is the impact of WCAG 2.1 on policies that reference WCAG 2.0 understandable and not disruptive?

So have your say and contribute towards digital more inclusive!