Accessibility: No Rights Without Responsibilities
This presentation talks about rights and responsibilities of people with disabilities and developers to work towards a barriers-free internet. It was originally given at Confoo 2013.
Updated for A11yTO. The presentation varies slightly from the blog post. You can grab the slides [PDF, 6Mb] if you want.
L’Internationale / Duties / Rights
Nic Steenhout talking about the Internationale Song.
As I grew up, my father was listening to Marc Ogeret singing revolutionary songs. One of the songs that played often was L’Internationale. Part of the lyrics say:
Equality wants other laws: No rights without duties, she says, Equally, no duties without rights.
L’égalité veut d’autres lois Pas de droits sans devoirs dit-elle Égaux, pas de devoirs sans droits
People with disabilities have been demanding access to websites, and rightly so. We say we have a right to accessibility. And we do.
But we also have a responsibility, a duty, to help along.
Lots of People With Disabilities Don’t Speak Up
Many people with disabilities who encounter barriers on the web don’t speak up. Most people I speak to seem to do one of three things. They either:
- Just move to another site without giving feedback to anyone,
- Swear a bit and then go to another site, or
- Go to another site and moan to their friends or on Twitter, without talking to the site owners.
There is a feeling that there is no point in providing feedback to site owners, that it is pointless to do so, because nothing ever changes.
Must Speak Up
People who encounter barriers must speak up if they ever want to see change.
In some ways, it is not surprising that website owners dismiss the need for accessibility. There is no easy way to see those needs. Accessibility needs aren’t tracked by web browsers. Web analytics track much interesting and useful information such as where someone comes from, which browser they use, which page they view, how long they stay on that page. But they don’t tell you if a visitor uses screenreading software, is Deaf, navigates with keyboard only, needs large font, is colour blind, or have any number of access requirements.
People often say “Don’t vote, don’t complain.” Meaning that if you haven’t voted, you can’t complain about what a government is or is not doing. It is the same thing with websites. We cannot expect anything to change unless we speak up and provide feedback. Another saying often quoted is “be the change you want to see in the world” (improperly attributed to Ghandi). I suggest something slightly different: If you want change, act to make change happen.
Disabled != Accessibility Expert
Of course, we must keep in mind that not all people with disabilities are accessibility experts. In fact, the vast majority of people with disabilities know very little about accessibility at large.
Just like a PHP programmer knows php well, but may know very little or nothing of C++, or Perl, or Java, people with disabilities tend to only have direct knowledge of what impacts them.
If someone is a wheelchair user, they may know about ramps. More to the point, they will know which ramps work for *them*. Perhaps the building guidelines call for ramps that have a 1:12 gradient, but that is too steep for this person – they will tend to say “the ramp is not friendly”, even if the ramp meets the guidelines.
Someone who is blind will have a very different experience on a website depending on how proficient they are with their adaptive software. Someone who knows the application well may be able to navigate a less than friendly page, whereas someone who doesn’t know the application well may find barriers even if the site is technically accessible. Neither of these people may understand access requirements for sighted people using keyboard only, or for people with hearing impairments.
One has to have a solid understanding of the various impairments, and barriers relating to these impairments, as well as understanding the guidelines before we can say they are “accessibility experts”.
As developers, we have to be careful to understand that if the feedback is “feature XYZ doesn’t work”, it doesn’t necessarily mean the site isn’t working accessibility-wise. As people with disabilities giving feedback, we need to be careful to give details about what wasn’t working so developers and accessibility specialists can investigate properly.
A Frustrated Developer Says
I recently had a developer with a disability I know email me to say:
“I asked for help on twitter, but as usual when I ask for #a11y help, nobody answered. Honestly? Blind people suck that way. If someone building a ramp asks my opinion I will be overjoyed to go over there and test it. Blind people will not help test websites. Ever.”
This person implemented accessibility to the best of their knowledge, but understood that nothing beats having user-testing to make sure things have been implemented properly. However, they could not find anyone to do testing for them. They were quite frustrated with the experience of not being able to find anyone to help.
High Demand on People With Disabilities
The thing is, people with disabilities are often asked to test sites, or building, or applications. It is heartening to see people who want to do the right thing.
At the same time, it feels like there’s an expectation that people with disabilities should give it away for free. It is as if we should test all the sites we’re asked to test because we have a disability and we want websites to be accessible.
As a disability rights advocate said, it appears our only responsibility is to educate people about life with a disability. Like we don’t have a life outside of that – we don’t have families, jobs, friends, etc.
If it were a question of doing one quick test, it wouldn’t be a problem. But “just 5 minutes” to check something never is. Invariably, the time demand on doing a “quick” site review takes longer than 5 minutes. A quick accessibility review can easily take up to an hour. Multiply this by every request for testing, and you end up with a lot of time eaten up. And there rarely are offers of compensation. The cumulative time demands could end up taking 25% or more of someone’s work week.
And while most people with disabilities are generally happy to help, there comes a point in all our lives where we are a bit burned out.
Is It Any Surprise, Really?
It is not really surprising that people with disabilities get burned out, lose enthusiasm for providing feedback or testing.
We have learned over time that it is often pointless to bring up accessibility issues. Feedback or complaints get nowhere. A large number of emails trying to address accessibility issues seem to end up in a black hole – never receiving a response.
When there is a response, it often is a terse email along the lines of “we’ll look into it” but nothing ever happens.
Or we’re told it’s too expensive to fix.
Frustration sets in.
Head, meet Brick Wall
I wear many hats. Among other things, I am:
- A person with a disability,
- A web developer,
- Aware of various disabilities,
- Aware of barriers faced by various disabilities,
- Intimately familiar with accessibility requirements of various guidelines.
There are three situations that jump to mind where I had the feeling that banging my head against a brick wall might have led to more results.
Joomla!
I was invited to be on the Core development team of Joomla! when it first split from Mambo. I was specifically brought on board to increase accessibility of the CMS. However after a year of work and discussion, and after refactoring all the code to demonstrate a proof of concept ironing out 98% of the accessibility issues on the frontend, there was no action from the team.
The general feeling was that an accessibility add-on should be provided, rather than build it right into the Core.
WordPress
“Once burned, twice shy” after my experience with Joomla!, I did not get involved directly with WordPress, but I kept a close eye on what was happening with it. I saw accessibility advocates get involved, get burned out, and leave. I saw other advocates try to do solid work towards improving accessibility of the CMS. And while I heard a lot of positive talk coming from the WordPress developers, I did not see all that much action.
With the number of people who have offered to help over the years, WordPress is still surprisingly lacking in accessibility. You just have to look at the bug tracker. Some accessibility bugs are still on the tracker several years after being posted, even some for which fixes were offered.
NZ Paralympic site
In May 2008, I contacted the New Zealand Paralympic website owners. Their website was thoroughly inaccessible. Which is somewhat ironic considering that they deal with athletes with disabilities – their own members couldn’t use their website! After contacting the owners, I was informed that they had hired a web development company to work on that.
A year later, some small changes had been made, but by and large, the same issues were being found. I wrote a post about the developer’s responsibilities in this case.
Over 4 years later, the site is STILL showing some serious accessibility issues.
Suggestions for Sites
What can site owners or developers do to address their responsibility of delivering accessible website? Obviously attempt to implement all appropriate accessibility guidelines. But also listen to their visitors.
- Conduct user testing – hire (and pay) real users with disabilities to test the site from the early stages on. Knowbility’s AccessWorks Accessibility & Usability Testing offers a pool of testers with disabilities for paid testing.
- Invite feedback – make it clear that you are interested in hearing if someone finds a barrier.
- Provide easy feedback paths – make it easy to provide feedback. An email form, as well as email link, a phone number, and where appropriate a physical postal address should be provided. If forums are provided on the site, invite comments there. Interact on those issues in the forum.
- Listen to the feedback provided. Don’t just ignore emails or other communications. Don’t just pay lip service to the feedback provided. People took valuable time to contact you, the least you can do is respect that.
- Don’t promise without delivering on the promises. It is very frustrating to be told “we’ll fix it”, yet after months or years nothing changes.
- And obviously, eliminate barriers as you become aware of them!
Suggestions for Visitors with Disabilities
Visitors with disabilities can also do a few things to help along.
- Prepare template emails – Most barriers you encounter will be the same or very similar. Instead of having to retype the same thing over and over, prepare a template text you can reuse. When you only have a few details to update in the email, you won’t lose as much time providing feedback.
- Take a minute to contact problem sites – Do take a minute to do this. If you can’t find contact information easily, forget about it. But if there is an easy feedback path, use it!
- Don’t just bitch! Provide constructive criticism. Elaborate what the issues are and what, in your experience, could resolve it. People react better to constructive criticism than to aggressive diatribes.
The W3C Web Accessibility Initiative offers a few thoughts on templates and contacting organisations about innaccessible websites.
Conclusion
We all have rights and responsibilities. We have a right to access, a right to information. We have a responsibility to help towards a barrier free online environment. We have a duty to listen.
If we all work together candidly, we will see results. We will get to a more accessible web. I say this not because it is cliché, but because it is true. Collaboration is the key to success.