How to Receive an Accessibility Complaint

In my prior post I discussed the forbearance required of accessibility complainants. I will now cover the other side of the coin: the response I'd hope to receive for accessibility concerns that have been brought to their attention by an end-user.

But first, I need to provide context.

As an end-user, I've personal provided several complaints and recommendations to developers and webmasters over the years. In my experience, I've heard a variety of responses:

• "We'll look into it and get back to you." -- and they often don't despite my follow-up;
• "I'm not sure how this could work."
• "We'd love to but we're too busy/have many responsibilities/are a small company." And, worst of all
• Silence.

There are certainly webmasters and developers who are fantastic. They'll pledge to update their app and follow through. But they can feel like a few-and-far-between crowd, so it can be hard as an end-user to give a busy developer the benefit of the doubt.

I also understand there's a process. With most companies, the developer won't receive an email directly. Often it will go to a contact person, who will pass it along to the development company. From there a project manager or account manager will prioritize it and put it into the work queue.

However, following the suggestions in this post will help this exchange move forward in a productive fashion by making the complainant feel listened to and acknowledged, while allowing developers to do what they do best.

Accessibility isn't just for those with disabilities

When you receive a complaint that's specific to accessibility, it's likely from someone with a disability. But many of those who will benefit don't have disabilities at all.

Captions help those wishing to watch a video on mute. Alt text allows Google to find and index your site. Enlarged images and colour contrasts help those whose eyes are not what they once were.

All of these people would benefit from a universally accessible site, but none will write to tell you so. They have the benefit of work-arounds; those with disabilities do not.

Understand the importance of accessibility and take it seriously

This suggestion above all others will change the dynamic of a conversation. If you understand and buy into my first suggestion, then this next one will come naturally.

Taking accessibility seriously means following the rest of my suggestions, but more than that, it means realizing the opportunity you can gain by making your products usable to everyone and the opportunity lost by failing to do so.

The seriousness with which you take accessibility concerns will be reflected in your response to the complainants and by your efforts to correct the concerns raised. Read on for more tangible suggestions.

Reply

We know developers receive many requests in a day, but make time for a response. Even if it's automated, it at least lets the complainant know that their concern has been received and the account to which they wrote is being monitored.

In most cases, it's not going to be the developer who replies, but rather the person who triaged the request. That could be a customer-service representative or an account representative. Just the simple act of letting someone know their issue has been acknowledged will help. And be honest – if you are going to do something, great. But if you can't, explaining why will help alleviate some frustration.

Differentiate between an accessibility complaint and a feature request

Now this may fully expose my entitled side, but I would like to believe that accessibility complaints are as serious as crash reports or similarly serious bugs. They are usability issues: none of my usual work-arounds work. Or, in the case of misleading or unlabelled form fields or links, there is no work-around.

This means that there is a significant feature or part of a site or app that is unavailable to me. Just as bugs are squashed first before significant new features are added, making a website or app work for everyone should be a top priority. Features are important, but access to all existing features by all users should be more so.

Admit what you don't know and seek out that information

If you have no idea how my adaptive technology works, or you've never heard of WCAG 2.0 AA Classification, tell me; I won't judge you for your lack of knowledge. Then we can work together to gain that knowledge so we can both use it in future.

If you're not sure how your software would be used by someone with a disability, consider giving access to customers with disabilities to function as voluntary Beta testers, or ask questions of others working in your platform for help. Consider Drupal's Statement on Accessibility, Useful Tools to make WordPress Accessible, Accessibility in iOS, and Android's page on accessibility.

Accessibility is a not a new issue, but for many in the industry, it's a new addition to their work considerations. At Digital Echidna, the accessibility leaders in the company have taken the time to educate themselves because they believe in the issue, but the fact of the matter is that we're all still learning, growing, and adapting. Every day new rules and regulations come, new technology gets developed, so accessibility is a constantly evolving aspect.

Provide the text label for links or buttons that you'd like me to find on your site

"The yellow hourglass on the top left of the page" is a great description, but if my screen reader says "images/timer/about_html," I won't have a clue where you're indicating. A hint like "The yellow hourglass that says something like 'timer' on the top left of the page" would suffice, as then I'll have an idea of where to navigate to. I understand that you may have no idea of my visual acuity, and even if you did, it's unfair of me to expect that you wouldn't refer to the graphics on your page at all.

Sending and receiving accessibility complaints can be a frustrating process for both parties, but it doesn't have to be. As long as each side is polite and gives as much information as they can, this can be a very positive experience.

Have you had similar interactions, either as a complainant or a recipient? What worked? What didn't? Sound off below; this is an essential discussion to have in forwarding accessibility awareness and implementation.