Seven Accessibility Mistakes (Part 1)

In: Articles

By Christian Heilmann

Published on January 31, 2006

There are several reasons inaccessible Web products get published. One we discussed in my last article is that some clients just don’t care about accessibility. Their reasons make a lot of sense if you put yourself in their shoes. Another reason is developer mistakes. Making mistakes is natural, and suffering the consequences and learning from them is what makes us better developers and better people.

Here are some of the major mistakes I encountered during my years as a professional Web developer. If we keep an eye open for them in the future, we are a lot more likely to create accessible, beautiful Web products without much hassle—and make both clients and visitors happy.

I’ve offered tips on how to avoid these mistakes at the end of each description. Following them may not be possible within the limits of your budget, or they may require a more mature relationship with your clients, but it cannot harm keeping them in mind. No step toward designing for the end user with the client’s ideas in the back of your mind is a waste of effort.

The Seven Accessibility Mistakes: 1-3

Mistake #1: Believing in products without putting them to the test

A lot of editing tools, frameworks and content management systems claim to create standards- and AAA-compliant sites. Many of these simply close tags and lowercase elements generated by WYSIWYG editors and enforce alt attributes on images. Neither of these is a bad idea, but they’re not enough.

Valid HTML isn’t necessarily semantically correct or logical—only humans can determine that. Don’t get me wrong, there are a lot of amazing tools out there. But they are just tools, machines that can’t understand human interaction issues. Machines can’t determine if the outcome makes sense, no matter how sophisticated they are. Halfway through a project you might find out that the CMS has a major flaw that was cleverly glossed over in the demo sites that came with it (UTF-8 compliance for international sites comes to mind).

What does this mean for development?

• Put aside a lot of time for developer training on the product (in the case of an IDE, this is a one-off investment).
• Document flaws and their workarounds. Make this document a mandatory part of the project hand-over to the maintenance crew or new team members.
• Enforce human testing in the deployment process. This can be done by a trained editor if there is no time for a full testing cycle.

Mistake #2: Taking too much responsibility

Let’s face it: A Web site will not stay within the scope of the original plan. Web sites have the tendency to grow organically, and that is the really cool thing about them. If you don’t want to be the one responsible for maintaining all changes (that is, unless you have a really trusting or rich client to pay you for your time) you’ll have to make sure the client knows about the ins and outs of your product.

Introducing yourself to the client as the accessibility superhero who fights crime at night in a sexy costume is a sure-fire way to failure. The issue is not that the client does not trust you—they’ll be happy to get rid of this responsibility. The problem is that you’ll get involved in the internal bickering of the client company and take on the whole responsibility.

A typical scenario: The marketing department comes up with some text that is totally inaccessible because it depends on the imagery that goes with it (probably taken from an ad campaign in another medium like print or TV). The project manager hands this text over to you. You explain the issues and he tells you that this is what marketing really, really wants and asks you how he should deal with the issue. You explain it to him and he forgets this or that small detail when reporting back to marketing. You play a childish “telephone” game, and end up spending a lot of time reiterating the obvious and going nowhere fast.

The facts:

• The client wants a Web product
• The client wants happy customers, readers, listeners or visitors
• The client is very likely to change everything for various reasons

The logical solution is to coach the client as soon as possible where accessibility snags are, and agree to stay within the limitations (which are not really that strict) when maintaining the product.

This also covers your lower backside if a client faces a lawsuit. Your rap should be, “We help you ensure accessibility,” not “We make your Web site accessible.”

What does it mean for development?

• Plan for client workshops and training on accessibility before you start developing.
• Find a champion inside the client company to take on responsibility for accessibility standards. There is always someone who wants to stand out, and this is a good chance—accessibility is a legal issue.
• Produce hand-over material on accessibility measures and how to sustain them through design changes.
• Have a clear and concise part of the project contract state that the accessibility of content after the initial project delivery (the day you go out for drinks to celebrate) is the responsibility of the client. Any input they need from you should be budgeted separately. This threat of extra cost will make the client push his people to listen to you more intently. Talk to your legal team to phrase this bit as if it is there to save the client money and protect them—legalese is a powerful weapon.
• Make sure you practice what you preach. Your initial content and code has to be immaculate. Mistakes will be copied, and it’s hard to explain to a client that your advice was wrong.

Mistake #3: Planning only for the worst-case scenario

It can happen that we developers, full of altruism for the disabled, lose sight of the big picture. But accessibility is about everybody, regardless of ability or geographical background. For many of us, the idea of keyboard access, voice recognition or even screen-reader users is something we hadn’t thought of before. Now we feel guilty and want to make up for it by fiercely thwarting anything that might make screen-reader use impossible.

Here’s a dirty little secret: A screen reader is also a tool that comes with own rules. Many Web developers believe myths about screen readers. Test one, or ask a person that is dependent on assistive technology how they use it and what they really need and want.

There is simply no way you can anticipate every constellation of ability, hardware and knowledge on the other side of the screen, and by cutting it down to the lowest common denominator you will not succeed in making the site accessible, usable and enjoyable by the majority of visitors. You’ll also perpetuate the myth that accessible sites have to be clunky and ugly.

The minimum requirements for an accessible site are:

1. Semantically correct, logical and valid HTML
2. Content that makes sense when being read or heard
3. Alternative text for any visual content
4. Headings and links that make sense outside their context

These basics are the foundation of your site. If all the extras you put on top of that do not diminish the functionality of this foundation, you are in the clear.

Extras to avoid are:

• Low color-contrast in graphics and CSS
• Color combinations that are not easily distinguishable for the colorblind
• Type that is too small or cannot be resized
• Overlapping elements that obscure each other at larger font settings

If you want to add some sexy JavaScript to allow for drag-and-drop functionality or drop-down menus, that is fine, too. Simply make sure the JavaScript only applies this functionality when the user agent can deal with it. Even better, make it an option or offer a way to turn it off in favor of an easier interface.

What does this mean for development?

• Ensure that the basics are covered first and show the client how well the site works for all kinds of different environments.
• Try to introduce the idea of progressive enhancement. Don’t start with visuals but instead with unstyled wireframes.
• Use tools that allow editors to write copy outside any visual framework. This could be clean Word templates or a simple publishing tool like WordPress.
• Demonstrate how covering the basics of accessibility helps everyone—browse the site on a cell phone or PDA.
• Don’t forget to praise the search-engine friendliness of good content.
• Don’t underestimate the power of CSS and JavaScript as a usability tool. As a user with JavaScript enabled, I like to find out there’s a problem before the whole page reloads.
• Design with usability in mind. Good graphic design not only sets the mood, but also makes it a lot easier for the visitor to find what is important immediately and without thinking too much.
• Design with flexibility in mind. Web sites should be able to grow both from an information architecture and screen-space point of view. Avoid filling up any space to the brim. Some day, new navigation links will be changed or added, or copy will be translated into a language with longer words.

Next week I will talk about the other four accessibility mistakes I have encountered:

• Sharing problems with the visitor
• Trying to solve problems outside our area of experience
• Hiding or overriding accessibility/usability enhancements
• Catering to the wrong clients

Related Topics: Accessibility