Seven accessibility mistakes you don’t want to make

Even those of us who work hard to build accessible websites make mistakes. Some of those mistakes directly affect the accessibility of the site, others may come back to haunt us down the line. In a two-part article (Seven Accessibility Mistakes (Part 1), Seven Accessibility Mistakes (Part 2)) published on Digital Web Magazine, Chris Heilmann explains some accessibility mistakes he has encountered and how Web developers can avoid them.

I recognise most of the mistakes from projects I have been involved in. Some of them are easier to avoid in future projects since it is mostly up to you and your development process. Others, however, have a lot to do with client demands and can be much harder to steer clear of.

The mistakes Chris mentions are (with my summary and comments added):

  1. Believing in products without putting them to the test. When a CMS or some other tool promises to create standards-based and accessible sites, don’t believe it until you have verified it. I have plenty of experience from working with content management systems that promise those things but fail to even come close.
  2. Taking too much responsibility. Don’t promise the client that the site you just built for them will remain accessible forever unless you will be the one entering all content and doing all maintenance work. Chris recommends coaching the client, which is the approach we try to use at my dayjob. It doesn’t always work, but at least we did try.
  3. Planning only for the worst-case scenario. Accessibility does not mean designing HTML-only sites with only text and no images. It means starting with the basics to build a solid foundation, and then adding progressive enhancements.
  4. Sharing problems with the visitor. When a client requests intrusive spam protection mechanisms and futile attempts at preventing graphics from being downloaded, explain why doing so is a bad idea.
  5. Trying to solve problems outside our area of experience. Try to resist the temptation to build nifty widgets that replicate browser functionality. Instead spend your time on educating the client and writing clear and simple instructions for the most commonly used browser functionality. This is the approach I prefer, and recently I have started putting this information on a general “About this site” page instead of on an “Accessibility statement” page. I write a bit more about my reasoning in Accessibility statements or Site help pages?.
  6. Hiding or overriding accessibility/usability enhancements. Make skip links visible and don’t mess with the appearance of form controls. I don’t always manage to make skip links visible at all times, but in the cases where that isn’t acceptable they do appear when you start tabbing. Not ideal, but better than nothing. I’m always very reluctant to attempt styling form controls. I don’t buy the “visual consistency” argument that is often used to defend making forms more difficult to use.
  7. Catering to your client—not their clients. Try not to give in to every client demand that you know will reduce the quality of the site. Almost everybody thinks they know enough about the Web to make critical design decisions. Not a lot of people actually do. That’s our job.

A few noteworthy quotes from the articles:

Don’t replicate what the user agent comes with. In a lot of browsers, I can bookmark, print and change the text size with user interface elements (like buttons) and keyboard shortcuts.

I really dislike replicating browser functionality. Luckily most of our clients listen to our arguments, so I rarely end up having to do that.

Chris also has some words of wisdom for the form control styling-happy crowd (often purely visually oriented designers who value appearance above function, usability and accessibility):

Although it might not be obvious at first, there are reasons browsers render form controls and links the way they do. If you want to override them […] you’d better have a really good reason and do some usability testing with real humans. Browser developers did that.

and

Whenever you try to improve the look of a form, you lose the benefit of instant recognition. Your changes had better be worth that.

Consider that and the examples I provide in Styling form controls with CSS, revisited before you start breaking form controls next time.

Posted on January 16, 2007 in Accessibility