Positive Impact of Technology on Lives of People with Disability


Technology has brought convenience and luxury for many however it is a necessity for people with disabilities.

I am writing this largely with the personal experience over a period. I wanted to write on how the technology has made the positive impact on people with disabilities for many years. I would like to specifically focus on Information and Communication Technology (ICT) space in this article.

There are many disabilities which cannot be cured or there is no medical solution. This brings to the point that one has to live either a limited life or a life with lesser opportunities based on how one defines disability. However, the technology has opened up many avenues and there are much more opportunities and possibilities for people with disabilities today compared two decades ago.


I would like to set the perspective to understand the impact technology has made by explaining how was the education space for people with vision impairment during late 1990s and early 2000 in India.

When I was studying high school, the options for people with disabilities were braille book, audio cassettes (recorded audio books) or a volunteer reading out for people with vision impairment. Each has its own limitations.

Braille Books

I strongly support the usage of Braille during the early studies to get hold of reading and writing. Also, it has numerous benefits on the overall development of the child.

Braille books were best options for self-study. However the availability of Braille books were limited to prescribed academic books. I remember there was a syllabus change and it took more than 18 months to get the first-set of new syllabus braille books. Remember there was only one set of books in the first batch. All we had to do was write our own braille books sitting days and nights together where one of the sighted or partially sighted teachers or friends read out the chapters in sequence and we had to write braille books by exchanging positions for every hour or less. The scenario for a teacher with vision impairment was worse as they either had to write the braille book on their own and there was limited time to prepare for the classes due to non-availability of the Braille books. Braille books also demand huge space for storing and ware and tare is high due to the nature of the books and way of reading.

Audio Cassettes

I am mentioning specifically audio cassettes instead of audio books as few may not know the cassette technology and how much time it takes to rewind and forward, jump between chapters and not to forget the space required to store the cassettes with proper braille labelling to identify the right cassettes. As there was no availability of Braille books for higher studies, one had to depend only on audio books on cassettes and there were only one or two NGOs used to prepare audio books through volunteers. The NGOs were flooded with requests and the highest priority was given again for academic requests. Thanks for the volunteers and handful of NGOs because of which most people with vision impairment could complete their higher studies. The availability of audio books was more compared to Braille books as the duplication was easy and many people used to volunteer for reading the books.

The audio books had their own limitations as one could not read the spellings and it used to take lots of time when one has to quickly refer a particular page or section.

A volunteer reading out would have many aspects to be taken care like; availability of the person, mutually agreeable time and it is taxing for a volunteer to read loudly for a long duration. The volunteer has to read the subjects which may not be of a great interest for the volunteer. Thanks to many friends and volunteers because of whom many people with vision impairment could finish their higher studies and competitive examinations.

Screen Reader and Technology

Introduction of computers and screen readers have provided a great deal of independence in many areas such as education, employment and daily living for people with vision impairment. Even though there the screen readers were used by few folks with vision impairment in late 1980s in India, screen reader usage and availability of computers has increased only towards the end of 1990s in India. There were few NGOs who used to provide computer training for people with vision impairment and the affordability of computers was not feasible hence the usage was limited to the shared computers in some NGOs or training and in the employment space.

We cannot even think today that very simple things like reading a newspaper was a daunting task just a decade ago for people with vision impairment.

Increasing digitalization and usage of computers has opened up many opportunities in the employment space as well. The newly opened up avenues for perceiving education and vast possibilities of employment has provided choices. Earlier there were very limited choices for a person with vision impairment in employment space.

Today we can find people with vision impairment contributing to the society in various fields. People with vision impairment are working successfully in various domains like; banking, teaching, software engineering, network administration, recruitment, etc., because of the ICT and assistive technology.

Not to mention this will enhance the quality of living and contribution to the nation’s economy as well.

Is Everything Fine?

It is very important that the applications should be accessible so that the users can use the applications using screen readers and other assistive technologies. Improving digitization and various door-step services based on apps like transport, food delivery, e-commerce, online banking, have hugely impacted on the quality of life for people with disabilities which demanded lots of effort and few were impossible just few years ago. Hence, it is very important to ensure accessibility is prioritized on all applications and ICT products. It is for another article how much real-world applications are accessible even after 20 years of Web Content Accessibility Guidelines (WCAG) came into existence.


The main intent of this article was to share my view on how technology has made the life easier for me and people with various disabilities. I wanted to share this on International day of Persons with Disabilities. I hope this will inspire few of you take accessibility seriously and ensure accessibility is included in all levels. Technology has brought convenience and luxury for many, but it is a necessity for people with disability.

CAPTCHA Muktha Bharatha (India without CAPTCHA)


The various initiatives such as Digital India and Accessible India are aimed at improving the digital access and accessibility of both physical and ICT respectively. India has gone on a very large scale digitalization in the last 5 years. It is right time to ensure all the digital platforms consider accessibility in all the stages from inception to product delivery.

Accessible India Campaign

The Accessible India campaign was a very good and effective initiative by the government to increase the awareness on accessibility in India. The sad state of affairs is even after launching Accessible India campaign almost 4 years ago and conducting numerous workshops to various stakeholders the state of accessibility has not been changed much on ground.
Despite having many initiatives such as Digital India, Accessible India campaigns, it is very important for India to move from accidental accessibility to rule-based accessibility. It is very important for the large organizations such as NIC to have thorough understanding and clear plan of accessibility along with the right technical skills on accessibility.

Is Everything Fine Except CAPTCHA Accessibility?

Almost all the government and public sector units (PSUs) completely ban people with disabilities using their platform due to inaccessibility.
In this post I documented my personal experience of using various government and public sector portals where CAPTCHA was one of the major barrier from availing the facilities. There were many more accessibility challenges. However, I felt if there were no inaccessible CAPTCHA I could have used the facilities with screen reader at least.

PMO Does Not Like People with Disabilities

The Centralized Public Grievance Redress and Monitoring System (CPGRAMS) to raise and track queries to Prime Minister’s Office (PMO) remains inaccessible for people with disabilities due to the inaccessible CAPTCHA. The ticket “PMOPG/E/2017/0495564” raised in 2017 has been closed without any resolution. Various tweets to PMO and MSJE did not yield even response forget about the remedy.

Ernet Too Does Not Want Me to Provide Feedback

Unfortunately, the feedback form on Ernet India also prevents people with disabilities from providing feedback as there is an inaccessible CAPTCHA. Please note that Ernet is the organization which was responsible for making 100 recently launched accessible government websites as per this news brief. (http://www.uniindia.com/hundred-accessible-websites-for-divyangs/india/news/1110894.html)

After observing many accessibility issues on the Ernet page itself, I did couple of Google search to get the list of all 100 sites which are launched as accessible without success. MSJE did not respond for the multiple twitter queries seeking the same data last year hence I took the route of online Right to Information (RTI).

RTI Platform Coupled with SBI Payment Gateway Says No for PWD

RTI is not at all happy people with disabilities using their platform so they decided to incorporate inaccessible CAPTCHA and some weird requirements for form fields which took multiple attempts to figure out the errors. The next hurdle was with State Bank of India (SBI) payment gateway having an inaccessible CAPTCHA. I still do not understand why a payment gateway needs CAPTCHA as one has to perform 2 step verification anyhow.

It took almost more than 45 minutes for me to complete the filing online simple RTI application otherwise it would have taken around 5 to 8 minutes. I could complete filing RTI only for the availability of Be My Eyes (BME) service.

Election Commission Didn’t Think that People with Disabilities Use Their Online Services

The simple Election Commission of India  voter verification page is also not free of the CAPTCHA monster and I could not verify whether my name was there in the electoral list. All the activities on this site is forbidden for people with various disabilities to whom solving picture-based CAPTCHA is simply impossible.

Few Recommendations for CAPTCHA and security

Many places does not require CAPTCHA at all like payment gateway where users are required to perform two step verification. Most of the portals provide access to the registered users where getting rid of the CAPTCHA is the best thing as the users are verified during the registration process itself.
There are many alternatives for CAPTCHA such as OTP based authentication, etc. W3C document on Inaccessibility of CAPTCHA has documented various challenges and solutions for the CAPTCHA in a detailed manner.


It is the high time India starts implementing standard based accessibility rather accidental accessibility. India has the second largest population in the world and digitization is happening on a large scale. It is very important to consider accessibility seriously by both government and all the businesses else a large group of people will be forbidden from participating in the economy.
I expect CAPTCHA Muktha Bharatha (India without CAPTCHA) becoming reality in a very short time so that most of the facilities are opened up for people with disabilities till the full accessibility is achieved.

Ten (10) ARIA Best Practices

The assistive technologies such as screen readers and speech recognition applications rely on HTML semantics of the page to convey the information such as heading, button, link, etc. The assistive technologies such as screen readers also use these semantic information to provide options to the users to quickly navigate in an application with special quick navigation keys apart from tab and arrow keys.


ARIA (Accessible Rich Internet Applications) is a specification from W3C which enables to provide the semantic information to the assistive technologies in custom built applications. It is very important to use the ARIA in a right way else it will not convey the intended information to the users.


This post will discuss 10 (ten) and basic best practices of using ARIA attributes in an application. These best practices have been identified by analysing various ARIA related accessibility issues found in various custom elements.


Please refer ARIA 1.1 specifications from W3C schools for the complete list of roles and properties.


Top 10 (ten) important and basic best practices

  • Ensure role and related aria-* attributes are on the same tag
  • Ensure the role and ARIA attributes are on the focusable tag for actionable widgets
  • The aria-label attribute should not be used without a role
  • The ARIA properties and roles should match the functionality and type of the element
  • All ARIA roles and attributes need to have valid and allowed values only
  • Avoid extra spaces and line breaks in the role and aria-* values
  • Do not use any roles without required parent / child roles
  • Do not use aria-hidden attribute on <body> tag
  • Use only allowed aria-* attributes for any role
  • Do not use aria-modal attribute

Ensure role and aria-* attributes are on the same tag

The roles conveys what is the element is and the aria-* attributes convey the state and property of the element. It is very important to ensure all the aria-* attributes for a given role are present on the same tag. The required and supported ARIA states and properties need to be on the same tag where the role has been provided. This ensures that the assistive technologies provide proper feedback to the users.

i.e., The role=”checkbox” conveys the assistive technology that this element is a checkbox and aria-label attribute helps the screen reader to read the label of the custom checkbox. If the role and aria-label attributes  are used in a different tags then assistive technologies will not convey the correct information to the users.

Wrong Example

<div aria-label=”Kannada”>
<span class=”customCheckBox” role=”checkbox” aria-checked=”false” tabindex=”0”> </span>

Correct Example

<span class=”customCheckBox” role=”checkbox” aria-label=”Kannada” aria-checked=”false” tabindex=”0”> </span>


Ensure the role and ARIA properties on the focusable tag for Actionable Widgets

The role and the ARIA-* attributes need to be on the focusable tag for all the actionable elements. If the role and ARIA attributes are provided other than the focusable tag then the assistive technologies may not convey the element type and state of the element while navigating with the tab. The change of the state of element is not read by the screen readers.


All actionable elements such as <input>, <button>, <a href=””>, <select>, <option>, etc. are focusable elements any role and ARIA attributes need to be on the same focusable tags. For any custom elements providing tabindex=”0” makes the tag focusable hence all the role and ARIA attributes need to be on the tag which has tabindex attribute.

The aria-label attribute should not be used without a role

The screen readers read the information provided in the aria-label attribute. However using the aria-label attribute on an empty element without any role result in few screen readers not reading the information. It is necessary to provide a redundant valid role for the HTML element if you are using aria-label attribute to convey the information. Some screen readers does not consider the text in the aria-label if there is no accompanying role.

Correct Example:

<a href=”” class=”next” role=”link” aria-label=”Next”> <span class=”rightArrow”> </span> </a>

Please note by default screen readers recognize an anchor tag with href attribute as link. However redundant role link has been added to ensure the aria-label text is read by the screen readers on all platforms.

The ARIA properties and roles should match the functionality and type of the element

The role helps the assistive technologies to identify the type of the element such as button, menuitem, listbox, option etc. The aria-* properties conveys the state of the element such as expanded / collapsed, checked / unchecked, selected / not selected, etc.

Based on this information, user will be able to know the state of an element and use right kind of keystrokes. If the proper role is not provided for the element then it confuses the user and at times results in users using wrong keystrokes and expecting different action. This results in poor user experience and at times not able to use the element at all.


An expandable button not having aria-expanded set to false initially with the role button is read by the screen reader as Just a button and user expects some action to happen that by activating the button and user will not know that there will be few more options presented.


All ARIA roles and attributes need to have valid and allowed values only

There are set of role and the values allowed for any aria-* attribute. Only these allowed values to be used for any role / aria-* attribute.

The aria-* properties take certain type of values only those type of values to be used else the information will not be considered by assistive technologies.


  • The aria-label takes only string.
  • The aria-labelledby takes only IDs. Using strings result in invalid.
  • The aria-setsize and aria-posinset properties takes only numbers (digits).
  • The aria-hidden, aria-expanded, aria-checked, etc., takes only Boolean values.
  • Last but not least ensure all attributes are spelt properly.

Please refer the W3C ARIA 1.1 specifications for the complete list of role and properties.


Avoid extra spaces and line breaks in the role and aria-* values

If there are line breaks or unnecessary spaces in aria-label property, screen readers read the same element more than one time with arrow key navigation. This confuses the user. Ensure always there are no unnecessary spaces and line breaks in the aria-label or any aria-* properties.


Wrong Example

The aria-label property has couple of line breaks between the text. When navigating with the screen reader arrow key navigation, the screen reader reads same checkbox many times.

<span role=”checkbox” class=”customCheckBox” tabindex=”0” aria-label=”I






Terms and conditions



The IDs referred in aria-* properties need to be space separated

There are few ARIA properties which take more than 1 ID reference to read the text such as aria-label, aria-describedby, etc. The IDs always should be space separated and there should not be any line break or extra spaces before and after.


Do not use any roles without required parent / child roles

Few roles are nested roles such as menu, listbox, grid, table, option, row, gridcell, etc. These roles need to be appropriately nested according to the specifications. Using these roles without the necessary parent / child roles always confuses the users and at times on mobile devices these just prevents users from navigating to the next elements with assistive technologies.


  • For any table / grid following is the hierarchy of the roles grid > row > gridcell.
  • For any menu such as top navigation bar: menu > menuitem.


Please refer the ARIA authoring practices and ARIA 1.1 specifications.

Do not use aria-hidden attribute on <body> tag

The aria-hidden=”true” hides the element / text from the assistive technologies but the same will be visible on the screen. Setting aria-hidden to true on <body> tag makes the entire screen not read by the screen reader so never set aria-hidden attribute on <body> tag.

Use only allowed aria-* attributes for any role

Few attributes are supported by specific roles. If any unsupported ARIA attribute is used then the intended information will not be communicated to the users and at times the assistive technologies may interpret the element incorrectly.
i.e., The aria-pressed attribute is used only on role button to indicate it is a toggle button whereas aria-checked is used on checkboxes and radio buttons to indicate the selected option in the group.


Do not use aria-modal attribute

The aria-modal attribute is a valid ARIA 1.1 attribute. However, using the same results in VoiceOver on iPhone not reading the text on any modal or popups hence it is suggestable not to use aria-modal attribute anywhere.



ARIA 1.1 roles model:


ARIA Authoring Practices 1.1


Building an Accessible Button with Anchor Tag

Ideally it is good to reserve anchor <a> tag only for links and use <button> or <input type=”button”> tags for buttons from the accessibility and usability point of view. However, for various reasons we build custom buttons with <a>, <div> or <span>. The five (5) important things to be taken care to ensure that the button is accessible (ADA compliant) are discussed in this post. Ensure there is an appropriate keydown function along with the things discussed in this article.

Following are the considerations for developing an accessible button with anchor <a href> tag.

  1. Do not remove the ‘href’ attribute
  2. If it is a button provide role=”button”
  3. Provide href=”javascript:void(0);” for all the custom links / button with the href attribute
  4. Do not miss the semicolon (;) in the href value when provided with href=”javascript:void(0);”
  5. Do not provide hash (#) as the href value

Do not remove the ‘href’ attribute

The href attribute provides the following enhancements for the anchor <a> tag and this makes the coding simple.

  1. Provides keyboard focus while navigating with the tab key.
  2. Ensures that the elements gets activated with the Enter key along with the click.
  3. Changes the mouse pointer when hovered to indicate the element is clickable.

If you remove the Href attribute all the above functionalities are lost and <a> is just like <span> or <div> tag.

If the href attribute is removed then provide tabindex=”0” to make the element focusable with the tab key and CSS to indicate that the element is clickable on hover & focus. The element will not be activated with the enter key unless there is a function for keypress or keydown event.

If it is a button provide role=”button”

When the element looks like a button and the functionality is similar to a button then add role=”button”. If the role button is not added screen readers read them as link and user expectation for link versus button is different.

Provide href=”javascript:void(0);”

for all the custom links / button with the href attribute.

Provide href=”javascript:void(0);” instead of href=”#” and do not leave the href value empty.

Do not miss the semicolon (;) in the href value when provided with href=”javascript:void(0);”

With the JAWS screen reader turned on the buttons without semicolon (;) in the end of href=”javascript:void(0);” do not get activated with the enter or spacebar on IE 11. This just shifts the focus to the beginning of the DOM.

Do not provide hash (#) as the href value

Screen readers read href=”#” as same page link if there is no role specified hence the user expects that the element just moves the focus to in the same page. Many browsers scroll the page to the top when href=”#” is provided. This creates usability issues for the keyboard only users hence it is good to use href=”javascript:void(0);” both with and without role=”button”.

Additional Notes

Ensure event.preventDefault() has been called appropriately in the keypress / keydown function.

Ensure that the elements get activated with only Enter and space keys. There need to be a condition to check the pressed key and the action should happen only for enter and spacebar keys else the elements get activated even with tab navigation.

The keyCode for Enter is 13 and keyCode for spacebar is 32.

It is good to use keydown event instead of keypress event as there are some cross browser compatibility issues with the keypress event.