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.


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


  1. That’s very exact, I’d just say also make sure you know what you are going to do for your client before you sign the project.

  2. January 17, 2007 by Daniel

    We honestly have the hardest time with #2. If we’re not performing the content updates or maintaing the site, a lot of our clients find a way to gnarl the code.

  3. January 17, 2007 by AndyPandy

    Could you please try to explain to a noob why you would want to make skip links visible? I thought they were meant for text based browsers and for the visually impaired?

  4. Thank you for your summaries.

    I think the hardest point is to convince your customer (or employer) to stick on these (and other points). For example many pages I did had to have “Back-links”, containing a history.back(). It took me years to argue our designer and my boss to stop this. But I did not manage to to make them understand why (and I believe that’s not fault ;-)). Or styled form-controls.

    I could write a very long list of issues — the point is if you are ‘only’ developer and your employer is resistant against understanding that makes your job really hard and sometimes frustrating.

  5. Nice list! I usually style my forms, not beyond recognition - but I often change borders and background-colours. Perhaps it’s all right to just style the background-color, padding and font and leave rest of attributes alone? Since the classic input and textarea borders are one of the main things that represent a form, they shouldn’t be changed. What do you think?

    AndyPandy: Skip links are also useful to people that navigate with their keyboard.

  6. One of the few “browser controls” that I sometimes implement is a “Print”-button - and I only do that when a client has asked (ordered) me to use a pop-up with no toolbars. In that case I do believe that a “Print”-button is appropiate, as many - actually, probably most - users don’t know the keyboard shortcut for printing.

  7. About the only styling on forms I even attempt is getting the input boxes to be the same width, and even that is beyond a lot of browsers, it seems.

    I think the best solution to a lot of client queries is to find a site they respect, and demonstrate that they don’t use whatever idea the client has come up with, and explaining why they don’t, and why the client’s site shouldn’t either. Works for the vast majority of ideas people have tried to force on me, including a client who wanted to know why they couldn’t see their adverts - it turned out they had a banner advert blocking system turned on, and they couldn’t see any adverts…

  8. Thank you for your summaries. You bring a great perspective to this… THANKS

  9. All of it is pretty solid advice. I’m guilty of a couple: Styling forms — which I try to do less and less — and hiding jump links using off-screen positioning (or the offset class as I normally call it) instead of the display property “none.” I don’t think it’s a huge problem doing that since the links are available on demand to everything but Opera (which users don’t tab anyway), and they are available to screen readers, text browsers, and without CSS support. Of course keeping them visible is the very best practice so I do agree with all seven items.

  10. January 18, 2007 by Curious Cat

    I was just interested in hearing how you might go about making a skip links link appear via tabbing, but remain hidden the rest of the time.

    I have like the previous poster kept them hidden (usually as the design demands), but made visible in the hi-contrast versions, I would however like to apply the tabbed version to the regular design - adding the actual link permantly is unfortunatly too much to ask for…


  11. Developing a completely accessible or standards-compliant website may seem intimidating at the beginning so it’s always advisable to go one step at a time. First, build a basic, functional website, and then, gradually, keep implementing improvements one at a time.

  12. The problem is that trying to focus on accessibility requires more time. Clients want to do the project asap because it’s cheaper for them. I do my best to explain why accessibility and standards are so important but sometimes I loose a client in this way.. That’s sad.

  13. #2 is really a hard one to deal with. I often have to deal with handing a project over only to let someone else be adding and updating content on a regular basis. You can never be sure that this will be done correctly or with any thought of doing it right. I always try my best to sign them to a maintenance contract so that I can handle all of that but it rarely works, they always seem to want to update and maintain things themselves.

  14. “Could you please try to explain to a noob why you would want to make skip links visible?” (AndyPandy)

    Because flash is annoying, and all flash sites are just asinine. What if I’ve been to the site 100 times already? Do I need to see the stupid flash intro, for kazillionth time all over again?

  15. January 22, 2007 by Roger Johansson (Author comment)

    Jun: AndyPandy is talking about links that let you skip straight to different parts of a page, like the “Skip to main content” and “Skip to secondary content (sidebar)” links at the top of this page.

    Skip links should be visible since they are also very useful to people who have mobility problems and/or use their keyboard to navigate.

  16. Our designer has been putting Skip To Content links like the one in the top left hand corner of this site: - mouseover it to see how it works - do you think that is visible enough?

  17. January 23, 2007 by Roger Johansson (Author comment)

    Matt: Well, it is better than nothing (and it looks nice), but since you have to hover over it to find out what it does I don’t think it’s visible enough. At the very least, using the keyboard to tab to the link should have the same effect as hovering over it. Even better would be to leave it visible. You can probably make it a bit dimmer until it gets keyboard focus.

  18. nice article, but shouldn’t we be designing for our clients, clients.

    I have had some people that have had crazy ideas about there particular product and how it should be marketed… some people need to remember that its their target audience that I am designing for, its their target audience that keeps the site going, purchasing products etc etc

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

    Would you share some of those arguments? Among accessibility-minded clients, type-size controls seem to be the first (sometimes only) request; among all other clients, I lose the fight against “email this page” and “print this page” about 90% of the time.

  20. Excuse my ignorance, but where is the problem in styling form elements?

    I thought the whole point of CSS was you could use nice accessible markup and still have nice visual branding?

    The google toolbar styling every form input yellow is a clear accessibility problem, but only because it’s ignorant of the text color used in the form.

    Am I missing something?

  21. Being a novice on web design, I deferred total creative freedom to my webmaster. Thankfully, he did an excellent job designing my page. I can understand customers wanting to put their two cents in the design of the sites but ultimately, the designer must be given some flexibility to articulate the comments, ideas, and vision of the customer to reflect as best possible the final product.

  22. February 17, 2007 by Roger Johansson (Author comment)

    Marla: Among other things I refer to the Swedish guidelines for public sector websites, which state that developers should not duplicate browser functionality for printing. That takes care of most public sector clients. Text size widgets are easily avoided by showing how easy it is for users to use their browser to change text size. “Email this page”… yeah, sometimes we do lose that fight.

    Harvey: Styling form controls, especially if they are styled because of “branding”, can make them less recognisable and will increase the users’ cognitive workload.

    CSS does not specify how form controls can be styled, so you cannot style them consistently across browsers and platforms: Styling form controls with CSS, revisited.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.