Katherine Lynch.org

Web accessibility is a great thing, and a necessity as the web advances with newer and better technology, with more and more content made available widely on the web.

But, more to the point, we can all agree on that. Web accessibility is a tough subject to teach, but it is a more necessary subject to teach than almost any other web-related subject. Interested developers can look up literature in print or online to learn about pretty much any other subject and get a good grip on it, and while the same might be said for certain areas of web accessibility, it cannot be said of web accessibility as a whole. It is a subject about people, and personal to every user we aim to help. I have never met web developers more passionate about their work than web accessibility advocates, and I include myself in this group.

However, web accessibility is still struggling to be understood and more importantly, adopted by the majority of web developers. There are any number of reasons to comprehensively define why this is, but I’ve come to learn through my own experience as an accessibility educator and researcher that there are several things that we as advocates must be careful to avoid doing.  These are all too easy to do, and can actually hurt our ability to share our knowledge with non-accessibility-minded developers who are interested to learn.

5. We assume that others don't know anything.

Let's say that you know a bit about mobile development, and want to learn enough to start incorporating it into your work, so you pick up an article that promises to help you get a handle on the subject...and the first 3 sections are about how mobile development is for screens that are tiny.

Even if your audience knows nothing of web accessibility, most of them likely know at least a thing or two about web and/or content development, and can infer much of the most basic web accessibility information (for example, that invalid HTML markup makes screen readers speak in tongues) based on the rest of your quality research data and information. There’s no need to reinvent the wheel each time you bring up web accessibility techniques.

It’s useful to sometimes consider your audience as you would a classroom of students. Just as students will likely glaze over if you start to monologue about things that they already know, so will your audience. A good way around this is to encourage active learning through active participation. Before reciting the explanation of  “What ALT text is” for the hundredth time, assume that your audience is likely acquainted with that concept. Ask for a quick show of hands if you’re not sure. Have all of these basic explanations in your reserve in case someone in your audience actually needs you to explain them, but unless someone does, don’t worry about including it up front.

A really great way around this problem was done by a colleague of mine, Dan Allen at Drexel University.  Dan presented a 45-minute Basics of Accessibility lunchtime brown bag. When introducing the challenges faced by disabled users, he started with an overview of commonly-used assistive technologies--and that was it. By explaining what a mouth stick is and how it’s used, he was allowing his audience to figure out for themselves what some bad design choices could mean for a person using one. This not only prevents you from losing your audience, but will also make the experience of learning about web accessibility far more personal for each person there.

4. We assume that others know too much.

If you have digested more than one presentation or article about web accessibility, you know that ALT text and header tags are the Golden Oldies of accessibility education. This is with good reason--if developers do nothing else, this is a quick, easy way to get some baseline accessibility in place for many assistive technologies. It is also one of the easiest concepts to get across in the limited time of a conference presentation.

One of the biggest problems for web accessibility’s complete incorporation into the majority of the web is the steep learning curve that comes with really getting involved in active development. The WCAG 2.0 documents are notoriously dismissed as long and hard to grasp, understandably, and especially for people who have no real background in web accessibility. Something that may be obvious to a web accessibility advocate, or a person who’s done even a moderate amount of research on web accessibility, may completely go over the head of a person just learning these concepts.

It is often a good idea to limit the amount of information covered in a presentation on accessibility. It is a hard transition for beginners to go from understanding the basic challenges for assistive technology users, to figuring out the best way to incorporate aria-live regions into their Javascript-based feed display areas.

That’s not to say that we should dumb down the content--far from it. A narrower focus for a presentation gives you the opportunity to really delve into that subject, and give the audience lots of information and opportunities to understand. It is also helpful to relate advanced concepts back to earlier-introduced concepts. One thing that I often find helpful is relating a programmatic solution back to a specific web accessibility challenge, allowing the audience to relate the concept back to their own mental image of the challenges posed, and also once again driving home the basic concept that, at its root, web accessibility is about people.

3. We get hung up on one cause of accessibility.

I’ve noticed something--when it comes to advocating specific practices, many web accessibility advocates tend to focus on advocating for the best user experience for one or two types of disability or assistive technology. It doesn’t happen maliciously--maybe the developer has a friend or loved one who uses a specific AT or uses it him/herself, which makes the cause more personal to him/her. Maybe the developer has specific programming skills that can make the user experience awesome in that particular situation. These are good reasons to teach about that particular branch of accessibility, to be sure, but when taking up a position in an article or presentation as educators on web accessibility as a whole, we can’t forget about the wider cause.

Referring back to #4, stressing web accessibility on the whole as a concept and then pointing out problems and solutions for just, say, screen readers is assuming too much of the audience. It often gives the appearance that just this one type of action really needs to be taken, particularly by developers who are new to accessibility, and/or may be looking for ways to quickly incorporate it into their daily development and existing projects.

If, for instance, you are teaching just about screen reader accessibility, this should be made clear in your materials, your presentation title, and your instruction style; make it clear that this is in no way a comprehensive look at web accessibility, but rather a comprehensive look at this specific problem. If possible, try pointing your students at comprehensive sources like WebAIM or WebAxe to learn about more areas of accessibility. Also consider co-presenting or co-teaching with another accessibility advocate who has a passion for a different avenue of accessibility in practice.

2. We try to convert people who don't need converting.

I always think it’s a shame when I read complaints from accessibility advocates on Twitter about how they wished some presentation they saw or article they read had delved more into the guts of web accessibility, rather than focusing on “why web accessibility is important.” It’s a wasted opportunity when we get a room full of accessibility advocates together and end up rehashing the same old stuff.

It's like going to the movies, buying a ticket, and the first 20 minutes of the film is just the actors trying to convince you that the movie you're about to see is actually really good and you should definitely stay and watch the whole thing.  The fact that you showed up implies that you're already planning to do that.  If it's good, of course you'll stay, and if it's dreadful, you'll still walk out, no matter how hard a sell you got at the beginning.  The film speaks for itself in terms of quality, and the same should be said of accessibility presentations to accessibility-minded people.

And chances are good that if you are giving a talk about accessibility, there will be accessibility-minded people in the audience, hopefully many thousands of them because that is just how cool this subject is. They may not know everything you’re going to say (hopefully not in fact, if you’re doing it right :)), but one thing you should not have to worry about doing is convincing them that web accessibility is something worth incorporating into their sites.

I can’t think of many other web development topics that so consistently feature a justification of the topic before actually beginning the presentation or article than web accessibility, and this is dangerous. It puts us as the advocates into a defensive position right off the bat, and this is unnecessary, at least in this situation.

The fact that web accessibility is important because it opens the web up to all users and provides a fair experience for all (whoops, there I go) is something that absolute beginners have to learn about web accessibility, not developers with even a nascent interest in the subject. As such, unless you are giving a talk or writing an article that is akin to a beginner’s guide to web accessibility, you don’t necessarily have to restate this opinion unless prompted, wasting precise time, slides, or word-count-limited characters on something that your audience already knows. The importance of why we are doing this should reflect in the rest of your instruction materials, and your true passion for the subject matter.

1. We blame people for not already knowing.

A few days ago, I accompanied my mother to a restaurant to book a private event. We told the hostess it would be for a small group of people--about 20. She asked anxiously if anyone in our party was in a wheelchair or had any sort of ambulatory problems. She asked this because, as she then pointed out, the section of the restaurant reserved for private events was on a raised platform, with two steps leading up to it. She’d had a party come the month before and to her surprise, one of the ladies was in a wheelchair. The hostess hadn’t even thought to ask; she hadn’t thought anyone might have a problem getting up there.

I’m sure that most of us have at least a few anecdotes like this; examples of non-disabled restaurant hosts, shopkeepers, secretaries, and web developers providing an inadequate or unusable product or experience for a disabled person, because they didn’t even know there was a problem. In some of these situations, they may have thought there was a solution in place (as in some of the cases described here), or had a reporting mechanism that went unused. In others, they may have just honestly never had to consider accessibility. But in none of these situations should these people be vilified for their ignorance to the problem.

In this environment, web developers who make accessibility mistakes become scapegoats rather than people who can help fix a problem. Opportunities to learn become opportunities to scoff and blame. Developers who are eager to learn and help become nervous and ashamed of the work they’ve done, and afraid to ask a question for fear of it exposing them as not being an accessibility expert.

It’s always more desirable to assume the best of people in this situation. Rather than treating a mistake as if it was done out of carelessness or maliciousness, realize that you as an accessibility advocate and specialist have a gift that you can share. We should take every web accessibility bug we encounter as an opportunity to teach in a respectful way.  If a private request (meaning, not as a public tweet or Facebook status update) for a fix or offer to help goes repeatedly ignored, then it’s of course reasonable to feel that it isn’t being treated with the importance that it needs to be.

Realize, also, that fixes take time. That restaurant my mother and I went to didn't yet have an accessibility solution in place for their party room, but they are working on installing one, and in the mean time, they're making sure to find accessible party spaces within the building.  While everyone should be incorporating accessibility measures from the get-go on development projects, it still doesn’t often happen that way. Many developers who are beginners in accessibility are not beginners in development, and have tons of already-released projects that work beautifully...until they apply the principles of web accessibility. If they want to fix them, we should help, and in such a way that doesn’t make them feel sorry for even trying. Rather than grumbling about how the resources out there are too basic and many developers don't understand web accessibility, get out there and help someone!

I’m going to lift this bit of this straight from my presentation, Advanced Accessibility in Drupal:

"If a developer wants or needs to learn about accessibility, and if we take up a position of education in the open source community, then we have a duty to help those who want to learn.

Particularly when a student is learning something because he or she is afraid not to know, a culture can emerge in which the student is afraid to ask, and therefore reveal that he doesn't know."

By no means do I consider myself the absolute expert on this subject, nor do I intend to dictate any standards here; these are just some thoughts that I hope will provoke some good ideas and discussion among us.  We all know that accessibility education is for everyone; we have the tools to teach. Let us all realize that we are in a uniquely helpful position to make the web a better place.