Eleven Steps to Help You Effectively Address and Resolve Online Accessibility Issues

While productive communication is a two-way street, the path can sometimes get rough – especially when you're dealing with potentially contentious issues like accessibility. However, with a little respect and strategy – including the 11 steps that I'm going to outline – you can make sure everyone gets where they're going with a much less-bumpy ride.

Criticism doesn't always lead to smooth driving and emotional potholes can be created. After all, those with accessibility concerns can sometimes feel left out when they're unable to access something their able-bodied peers can. Conversely, no developer (or anyone, really) likes to hear that their creation is flawed. But there are ways for this communication to be productive and beneficial for both sides.

In this, the first part of a series on effectively expressing accessibility concerns for maximum results, I'll focus on best practices for those expressing a concern or formally issuing a complaint.

If you're writing to someone about a problem with a site or app's usability, keep the following in mind:

The webmaster or developer you're contacting may be new to accessibility

Even if they have some prior experience, they may be unfamiliar with current accessibility guidelines. Developers have many expectations placed on them and many areas in which they are expected to have at least a working knowledge.

While it may be tempting to rant in an e-mail to a webmaster or app developer about WCAG 2.0 AA or AAA compliance, the reality is that they may not be fully versed in it as yet. In Ontario at least, due to the implementation of AODA regulations, this is improving, but we still need to be patient.

Explain your disability in terms of how you use technology

My family members and I have had to explain to strangers that I don't need sign language to communicate. Many people don't appear to know the huge chasm of difference between Down's Syndrome and autism -- and those may the only two intellectual disabilities of which they've heard. People have probably heard of the condition of cerebral palsy but may have no idea what it means.

Your description of your disability doesn't have to be comprehensive, but stating something like "I can't see where to click so use the keyboard instead," or "I don't have enough dexterity in my hands to type, so I speak to my computer instead," should suffice.

Reproduce the problem, step-by-step

Saying "your site is inaccessible!" is likely the least-helpful phrase a developer can receive. It is your responsibility to tell the developer exactly what you were trying to accomplish, what you expected should happen, and what actually occurred.

Include URLs where possible. Write down the actions you took, in order. This also includes listing the browser, adaptive hardware and/or software, and the operating system of the computer or table you used – preferably with version numbers for each.

If this is the first time they've ever heard from someone using adaptive technology, they need to know exactly how you accessed their site and the process you took. Even if you don't use adaptive tech, this is considered a common courtesy to make the developer's life easier and to allow you to get the answers you need more efficiently.

Know how to perform basic mouse commands, even if you don't use one

This not only helps you tell the developer what steps you performed in their language, but also allows you to back-translate their suggestions into the keystrokes or voice commands you need to follow them. (Hint: double-click activates/opens an item, and right-click takes you to a context menu for a specific item).

The reader of your note may not be aware that there are, technology permitting, key combinations or voice commands to do this and may also not know how else to advise you when suggesting troubleshooting steps.

Provide tangible examples

This may include copying and pasting the output of your screen reader by selecting certain elements in a webpage and pasting them into a text editor (if possible). This will help the developer see what you're hearing: what is read out to you may not be what they intended. An example of this is poorly labelled images or links which may be read by a screen reader as (image001.jpg but appear visually as something else entirely. Obviously, adapt this to your specific hardware or software needs.

Actually take the advice they suggest

Even if you're pretty sure it won't work, try it anyway. They are the experts in their own application or site and can best advise on their own products. It also helps keep the discussion respectful. If you say, "I can't. I know it won't work," you're closing the door to discussion. It's fair to seek clarification on the reasoning for a suggestion, but don't dismiss it outright.

Ask for timelines and follow up

If a developer replies with a specific or expected completion date for a more accessible update, or suggests contacting them after a set period, take their lead and follow up during those times only.

Writing too often can be seen as pestering and you don't want to alienate the one person or group who could make a difference. However, failing to follow up may mean your complaint falls to the end of a long priority list.

Be persistent

This may seem contradictory to the last suggestion, but if you're told "Oh we'd love to. Maybe in a future update!" or something equally vague, write again. If you're writing to Customer Care and don't feel like you're getting anywhere, ask for a direct means of contacting a developer. If that doesn't work, try social media. This will both raise awareness of the issue and perhaps let them know you're serious in your insistence that something be done.

Stay professional

This is a must. No matter how irritated you become, do not resort to the, "they must not care about the disabled" post on Twitter, or a public Facebook shaming.

This will undermine your complaint and future complaints of others about any accessibility concerns, as developers and organizations may feel they have to be on the defensive from the first.

Find an alternative and use it

This isn't always possible, but if you can find an accessible alternative and have gotten nowhere with your first choice, use the alternative and inform the offending developer that you've done so. You'll drive home the point that accessibility done wrong will cost them customers.

Praise the developer if positive changes happen

Even if a website or app isn't 100 per cent accessible or usable yet, praise them for taking steps in the right direction. People like to know when we're doing something right and most feedback we get -- especially online -- is criticism. Take the time to praise progress like you did to ask for improvements. Don't let them off the hook though. Follow up if there are remaining issues or if an update causes accessibility to break again.

This may sound like an exhausting list, but much of it is common courtesy. Though websites and apps are used virtually, they are human-created and designed, and the humans that create and design them must be treated with respect. Having open, persistent yet respectful dialog will make universal access an easier goal to achieve.