Skip to main content
Posted in



Year in Review 2017

It has been a transforming, exciting and a fantastic year! Highlights of Accessibility developments in 2017 across the world.

In addition, we have added a few more sections such as Tutorials, Videos, Helpdesk, Knowledge base and made our social channels including Facebook and Twitter.

In 2018, we are planning to roll-out a few video series and if possible a few roadshows on raising awareness about accessibility.

Should you have an idea that we should do in 2018 and would want to join hands with us, please let me know.

We wish you a very happy & prosperous 2018.


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.

Accessible Rich Internet Applications (ARIA) Working Group of W3C has finalized several documents.

The Accessible Rich Internet Applications Working Group of W3C has finalized following documents:

Below is an excerpt of the announcement from ARIA working group:

The Digital Publishing WAI-ARIA specifications were co-developed with the Digital Publishing Interest Group, which has since become the Publishing Working Group.

WAI-ARIA 1.1 adds a variety of new features that were identified as needs since WAI-ARIA 1.0 was completed. These include a static table model to complement the dynamic grid model provided in WAI-ARIA 1.0, supporting news feeds and modal dialog boxes, better supporting labeling and extended descriptions, allowing authors to indicate keyboard shortcuts and custom role types, and refining the owned roles model and set of properties for many ARIA features. Digital Publishing WAI-ARIA Roles takes this further to provide roles for types of content that often appears in digital publications. Accessibility API Mappings describe how these features should be mapped to the features of Accessibility APIs specific to various platforms that user use to access web content.

WAI-ARIA Authoring Practices 1.1 has undergone major enhancements to reflect this work and provide web content authors with practical guidance about how to use WAI-ARIA in web content, including steps they need to take beyond WAI-ARIA itself to provide full accessibility support. A major part of the document is a set of design patterns for various types of widgets that explain how to create the widget using ARIA features and recommended keyboard interaction to achieve a familiar and predictable user experience; these design patterns are complemented by a comprehensive set of examples with working code that demonstrate the design pattern in action and provide authors a starting point for coding their own versions. The document provides comprehensive guidance about how to make content accessible to keyboard users, and also provides information about when *not* to use WAI-ARIA in preference to native features. Further information about this is available in the blog post:

WAI-ARIA Authoring Practices 1.1 Note helps authors make content accessible

Following the completion of WAI-ARIA 1.1, the Working Group will begin work on WAI-ARIA 1.2, which will focus on defining features that correspond to existing HTML 5 features. This reflects convergence of an accessibility taxonomy for the web across various technologies and will support future scripting and automation of accessibility features. More information about the Accessible Rich Internet Applications Working Group is available from its home page:

There has been great developments in th4e accessibility space during 2017. Way to go!

Tips to make your website more accessible

This is a guest post by Jackie Edwards.

Tips for accessibility

All websites need to cater to all of their users, including those with disabilities, but sadly many websites do not. For instance, in India all government websites are required to follow guidelines that ensure that the websites are accessible to everyone, but a survey of over 1,000 websites found that less than 1% of the websites actually meet the requirements.

This shows that there is an issue with how accessible websites are in India – and the issue is preventing millions of disabled people in India from having a simple online experience. Thankfully it is easier than you may think to improve website accessibility.

Here are four tips to make your website more accessible.

Use periods when you are abbreviating

There are over 10 million people in India with a visual impairment disability, and many of them use screen readers to read out text on websites. However, this can cause problems if you don’t put periods in the right place as the screen reader won’t read the text properly; for instance, if you write FBI instead of F.B.I the text will be read out as “fbi”.

Use subtitles and sign language interpreters

If your website includes videos, you should add sign language interpreters or subtitles to improve website accessibility. After all, there is an estimated deaf population of between 1.8 million and 7 million people in India, so if you don’t include subtitles you could exclude a significant chunk of your audience.

Label images

You should also add labels to your images to make it easier for the visually impaired to use your website. Many people who are visually impaired use assistive technology to help them decipher websites, but this can be difficult if you don’t include labels on your images as the technology can’t ‘read’ the image. If you provide a label describing the image the technology will be able to read that to the user, making it possible for them to enjoy the multimedia aspects of your website as well as the text.

Be aware of your audience

You also need to be aware of your audience if you want to make a more accessible website. There are a range of disabilities, from hearing impairments to cognitive impairments, and it is important to address each issue so that you can provide a useful service.

There is certainly pressure in India for ‘digital India’ to grow and progress, but there are still thousands of Indian websites that are not accessible for people with disabilities. Don’t get left behind – join the movement to make your website more accessible and progressive.

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!

Accessibility beyond the legal requirement

On 6th December, 2017 – I have got an opportunity to speak at Thomson Reuters as part of their events on the eve of International Week of People with Disabilities. It was fabulous to see participants from diverse groups.

I have talked about how accessibility creates more impact and benefits other than just a checklist item or legal requirement. Objective of this presentation is to promote business case put together by Web Accessibility Initiative Group of W3C.

Full text of this presentation will be published soon but here are the slides for now.

Some photos from the event:

International Day of Persons with Disabilities 3rd December

3rd December of every year is observed as International Day of Persons with Disabilities. Objective of observing this day is to raise awareness about people with disabilities and bring them to the mainstream. As we are gearing up to mark International Day of Persons with Disabilities, I would like to spend a few minutes and pen my thoughts how lives of people with disabilities have changed over a few years.

Before technology came into existence, people with disabilities has to depend on support for almost everything. May it be a blind person who would like to read a printed material, may it be a person loco-motor disability who wish to go for shopping, person with hearing impairment, who wish to communicate etc.,

Technology has addressed a lot of problems and brought independence to lives of people with disabilities. Today person with blindness can have access to digital books, convert any printed material to digital format and read independently, there are libraries like Bookshare and Sugamya Pusthakalaya, who brings together efforts of accessible books, access the wealth of information around the world, communicate to their friends and relatives using digital channels. Through the advancement in technology, opportunities for employment in the mainstream have been increased.

Again, with the advancement of technology and evolving e-commerce industry, it has become lives of people with loco motor disabilities more independent. Most of the shopping malls are inaccessible to wheel chair users; though a few brands have recently introduced Shopping Assist programs, it is still not as joyful as shopping independently. Online shopping has made this possible whereby users can shop from their location and things get delivered. Most importantly, online marketplaces may have more options than those available in the physical stores.

But what is lacking is that though there are advancement in assistive technologies that enable people with disabilities to access the technology, most of the technologies remains inaccessible; this is because due to lack of awareness about accessibility. There are enough resources available but what is important is that introduce those resources to developers at the stage when they actually learn to code! Accessibility and standards should be incorporated in the mainstream technological courses at school, college or whoever offer technological courses.

There is also a part that has to be played by users with disabilities. When user finds something unusable, write a detailed note to the app developer and keep following up until there is a response. While reporting, ensure to include some resources that helps them in resolving the issue. Another advantage of providing resources is that adds encouragement for developers to investigate the issue.

To conclude, here is an idea – starting this month, let’s meet one developer a month and educate them about accessibility and let’s see how many people we could impact by International Day of Persons with Disabiolities in 2018.