Ripple Effect of Inaccessible Tools and Potential Dollars Lost

Some of you may understand the direct relationship accessibility has on the effectiveness of people using assistive technology with the tools you develop or deploy from practicing techniques or objectives in Web Content Accessibility Guidelines (WCAG) 2.2), Revised 508 Standards and 255 Guidelines, ETSI - EN 301 549 or other guidelines and requirements. It is less likely some of you may understand the ripple effect of inaccessible tools, (software, hardware, web pages, services and processes) have on potential dollars lost or time wasted. Others who use assistive technology and experience accessibility barriers first hand can understand the negative impact inaccessible tools have on their productivity.

I am grateful several developers and some individuals who procure tools understand the benefits of incorporating accessibility into the developmental processes or tools they deploy. This minimal amount of attention to quality goes a long way to assist in reducing barriers resulting in increased customer base, customer satisfaction and effectiveness.

If you are unfamiliar with assistive technology or how a person who is completely blind uses a PC and experiences some of the accessibility barriers I will be describing later in web application number one and two the short scenario below may assist you in understanding the concepts. As a screen reader (one type of assistive technology) user I attempt to do some on-line shopping for groceries in a very simple web application. Once I start to process my order I quickly find the drop down list to select the method of delivery cannot be activated by keyboard commands (screen reader users generally do not use a mouse) or the results are not read to me as I scroll through my possible choices. Therefore I cannot choose how I want my order to be delivered. I also find when I tab to three different form fields I am not able to determine what I am to enter into these unlabeled form fields or even if these fields are required since they are not properly labeled with a description of what I am to enter. As I had to skip these unlabeled form fields since I was not sure what they are used for I wondered if one of them was for me to type in what I wanted to order, although I did not want to guess and pay for something I did not want therefore I continued. I did find a form field which was labeled for a telephone number, although the form field element did not specify the format I was to use (e.g. use dashes in between area code and.. or leave out dashes or include the country code). Due to these accessibility issues I was prevented from proceeding to place my order because I was not able to fill out all of the required fields or enter the telephone number using the correct format, therefore, I was not able to receive the groceries I needed.

Some developers, businesses and corporations might think it is too costly to develop tools that are accessible or usable. However, developing accessible tools can go beyond helping the employees or customers to be more productive, self-supportive and effective. Accessible tools can also potentially save money if one considers the ripple effect of inaccessible tools.

Below is just one of many possible examples:

Web Application Number 1:

• A person using assistive technology attempts to enter time critical data into a simple web application with just a few user interface elements (e.g. form fields, drop down menus, user notifications and a submit button) and found the application had accessibility barriers preventing them from accomplishing the task themselves.
• The affected person then locates anyone they can find who can help enter the data into the web application on their behalf.
• Although they did find assistance, the person they found was unfamiliar with the application. Therefore they did not notice an issue with entering the data and thought all was submitted without issues since the web application submitted the data without errors or alert messages.
• After the data was processed the result did not get processed as expected resulting in a missed deadline.
• Subsequently the person who had assisted went back to verify that the data they entered was correct, entered on time and was not processed as expected.
• The next step was that the affected person now was required to submit a help ticket to attempt to correct or explain the issue generated by web application number one.

Web Application Number 2:

• The affected person who uses assistive technology then attempted to enter a help ticket into a very simple web application with a few user interface elements to request help and found this help system also had accessibility issues preventing them from entering the case effectively.
• Then the affected person who uses assistive technology found another person who was unfamiliar with application number two to request help on their behalf to enter the help ticket regarding web application number one.
• Since the process for receiving an answer to the submitted help ticket using the fictitious accessibility work-around was becoming very time consuming the affected person contacted the person waiting for the information generated by web application number one and others affected by the delay in a resolution.
• After the help ticket generated by web application number two was received by an agent they found the request was unclear. This required a few back and forth conversations by email to attempt to resolve the issues since the help desk person could not be contacted by telephone to quickly explain the issue verbally to help overcome any language differences or barriers.
• This lack of resolution resulted in yet another group getting involved to help resolve the issue generated by web application number one.

Although what I describe above should have been a quick task of entering very little data into a simple web application with just a few user interface elements that could have possibly been resolved by the developer utilizing resources like "Labeling Controls- Forms WAI Web Accessibility Tutorials” it had become a long process. By the time the issue was resolved at least six people over several days were involved. This could have been avoided if the people who procure tools insured they procure accessible tools or if one web application developer or their team incorporated accessibility into their web application.

If end users, businesses or corporations could capture the potential dollars and time lost for every one of these individual ripple accessibility obstacles affecting many people I describe above by incorporating accessibility into the applications, services and processes, individuals, businesses or corporations could save many dollars to reinvest into the businesses or people. Incorporating accessibility will also empower end users enabling them to be more effective allowing them to flourish and prosper without the false ceilings of inaccessible tools.

Even though my example of how many people might be involved to provide a work around to accessibility issues with tools is hypothetical, I am sure some of you might have real examples to share.

Does anyone have examples of how tool developers and procurement individuals can increase accessibility and get the required sponsorship to make positive changes?

Any thoughts to help advance the enabling of all to flourish and prosper without the false ceilings of inaccessible tools?

Does anyone have additional information or input to contribute to this conversation?

I look forward to hearing your valuable comments to help us continue this important accessibility discussion.

Bill Tipton

Contributing Author,

Global Dialogue Center

http://www.globaldialoguecenter.com/

LinkedIn: http://www.linkedin.com/in/wdtipton

Facebook: https://www.facebook.com/bill.tipton.39

Twitter: http://twitter.com/wdtipton 

Comments

[Michael Renfro]

Thanks for another great article Bill. We have recently been working on evaluating and helping a team improve the accessibility of some software related to healthcare. It introduced another major issue in requiring users with disabilities to use others for help. That issue is privacy.

If the forms are inaccessible in similar ways to what you described the affected person must share private information with a helper to complete the tasks.