Last week, a second United States federal judge ruled that state anti-discrimination laws do not apply to airline websites and kiosks. Following this decision, JetBlue staff have reacted rather crassly to the court’s decision, posting Twitter messages like the following: “We’re glad that the court validated our position that state law should not impact a DOT controlled space“. These events have compelled me to speak on a topic I’ve only briefly discussed before: Users must take ownership of their role in creating a more accessible world by becoming their own advocates. If JetBlue or other companies remain ignorant of why accessibility is important, I feel it is time for disabled communities to make sure they know why they should care about accessibility.

We’ve all heard this idiom before, no doubt: “The squeaky wheel gets the grease” but few actually take the time to understand why it is so important to be the one who is doing the squeaking. Psychologists like Robert Cialdini will explain that it is often because people tend to feel others will do it or that perhaps others are already doing it. Or maybe if it was worth doing others would already be seen doing it. They may also feel that they don’t want to be seen as difficult or a trouble maker. No matter the reasons why, I don’t feel that users who have accessibility needs are taking enough ownership of this part of the process. If there’s a problem and nobody knows about it, is it really a problem?

Users’ Role In Pushing Web Accessibility

A product or website’s features are determined by two things: The specification and the background of the development staff. When it comes to the background of the development staff, the design/ programming/ production habits of those involved in development guide how the work gets done in cases where the specification is incomplete or unclear. In plain terms this means that how they do it is how they’ve always done it, so if they’ve neither been trained in accessibility and never been required to do it then it won’t get done. As I often say, developers aren’t evil for not building accessible systems, but rather uneducated in accessibility. When it comes to the specification the blunt answer here is if it ain’t in the spec then it ain’t getting done. Development staff – especially at large organizations – are constantly under a mountain of feature requests and bugs. Project management staff are tasked with the responsibility of determining which specific features and bug fixes are included in the next release. The developers themselves are tasked with marching to the orders of the project managers. The project manager is responsible for making sure the product ships on time and within budget.
So where does accessibility fit in? How does accessibility get included in the list of things included in the next version? Someone (quite probably an executive) asks for it to be included.

It is so simple it seems almost suspicious: All you need is for an executive to say so. But how do you get an executive to say so? An executive must be convinced that there is a compelling business reason for their product to be accessible. That reason can be on of three things: increase in income, cost savings, or risk mitigation. While it would be nice if people did things because they were the right thing to do, that’s just not the case. If an executive isn’t already on-board with accessibility, chances are it is because he hasn’t been convinced about the business reasons for accessibility. The missing link then, is this convincing of executives. Users who have accessibility needs have a very powerful role in making this happen. In fact, users can provide evidence of all things I discussed above:

  • Increased income: Users, regardless of accessibility need, may mean money. Bottom line is they’re customers, regardless of their specific accessibility needs, and the executives need to understand that their inaccessible system is blocking them from making money.
  • Cost savings: Users who need additional support cost money. This is especially true for e-retailers or other companies that make money online (such as airlines). Users who need to call, use the help desk, or use support chat because they can’t do things on the site cost money. While it is true that support people get paid no matter who they help, the support calls caused by accessibility issues are tracked as expenses and these sorts of calls would not be made if the system was accessible.
  • Risk Mitigation: Users taking their business elsewhere is one form of risk. Users who take them to court is another risk.

No matter which of the three reasons is more impactful for the executive, they won’t know about it unless they’re told. The first part is telling them.

How to make executives aware

This is the practical advice section of this post. Users need to contact companies to let them know they cannot use their systems. The more users who contact them, the better. Nobody makes a business decision because one (or a few) people contact them to complain. In fact, I’d argue it is bad business to make a decision based on the complaints of only a few people. But a large volume of people who all say the same thing? Well that’s a different story altogether! As the saying goes: the more, the merrier. The more people who make the same claims of difficulty in using a system, the more likely it will compel someone to act. Don’t worry about whether anyone else has complained, just do it. While you’re at it, get your friends, family members, classmates, and co-workers to do it as well.

If the system is internal

An internal system would be something in use by your employer or school. In many ways it is easier to make people aware of accessibility problems of internal systems. The reason is pretty simple: if you cannot complete your work or school work, then this is an immediate problem which impacts one of their own. An employee who can’t work is a tangible problem. Using whatever internal systems exist (such as a help desk or support ticket system), contact the company to register a request for help with using the system(s) in question. Be very clear about what you’re trying to do and why you cannot do it.

If the system is external

An external system would be something outside of your employer or school – things like public websites or supplier extranets and so on. The Web Accessibility Initiative of the W3C has created a great resource which discusses Contacting Organizations about Inaccessible Websites. The important part is to describe the problem including where the problem is, what the problem is, describing your environment, and what you’ve done to find a workaround. This allows them to diagnose the problem so that it becomes less about some anonymous person who can’t use the system and becomes a technical problem which needs resolution.

The W3C document I cite above also provides guidance concerning how to find the proper people to contact. I’d like to propose a possible alternative, if any of the W3C recommendations don’t work out. This one is courtesy of a conversation I had with Rob Yonaitis who had an idea that perhaps a user could try contacting Community Relations. Reading the Community Relations pages for any company demonstrates why:

A comprehensive, ongoing community relations program can help virtually any organization achieve visibility as a good community citizen.

Community Relations people are charged with the task of ensuring that the organization looks good to the public. They have a vested interest in making sure there’s a general positive regard for their organization. Community Relations people will not be able to fix the accessibility problems on the system, but because of their role they may become your instant champion in the company. This is also where the squeaky wheel may get the grease fastest, and the more wheels that are squeaking the better. If the community relations staff get the impression that the company is not doing its best at serving a specific segment of the population they may take action to bring the matter to the attention of those in the organization who can play a role in addressing the issues.

Submitting Support Requests

No matter whether the system is internal or external, help make the case by ensuring your report contains clear details on the following:

  • Your full name and necessary contact information, in case they need to contact you for follow-up
  • Your system environment, including operating system & version, browser brand & version, and assistive technology brand and version
  • What you were trying to do, including all necessary steps to replicate the problem, expected results and actual results.

There is no such thing as too many details. Chances are they won’t need every single piece of information above, but let them make that decision. In my opinion, the more clear it is that the issue is a technical issue which impacts real people, the more likely it is to gain traction.

Your calls will not fall on deaf ears

Chances are, there’s probably already someone at the organization trying to fight for accessibility. The problem they have is a lack of authority and/ or budget to make things happen. Users who contact the organization will be helping these people significantly.

I remember a time when I was on a contract at a very large US Federal agency which happened to have a lot of employees who were disabled. The 508 office frequently got calls from these employees whenever they had difficulties using internal software or internal web-based systems. The problem was, the 508 office was not tasked with maintaining these systems and had little direct influence on the systems’ management. As a consequence, calling the 508 office was of little help. In response, however, the 508 office recommended that these users submit a support ticket. This is because support tickets get tracked in a system designed for that purpose. As I mentioned before, this allows the accessibility issue to become less about one person who can’t do something and more about a problem that needs resolution. The more support tickets submitted for accessibility problems on a system the better.

No Complaints Means No Problem

In the end what matters is that if people don’t know a problem exists then that means they won’t do anything to fix it. While I’m personally of the opinion that those involved in managing and developing ICT products and services should be doing so with accessibility in mind, the reality is that they aren’t. They aren’t for two reasons: they don’t know how and they haven’t been convinced of accessibility’s importance. I remain optimistic that few people are so inconsiderate that they’d ignore accessibility once they were shown that real people are impacted by inaccessible systems. The first step in that process is for users to step up and take on the necessary role of letting organizations know when they face difficulties with their use of ICT.

My company, AFixt exists to do one thing: Fix accessibility issues in websites, apps, and software. If you need help, get in touch with me now!