Digital Web Magazine

The web professional's online magazine of choice.

Seven Accessibility Mistakes (Part 2)

Got something to say?

Share your comments on this topic with other web professionals

In: Articles

By Christian Heilmann

Published on February 6, 2006

This two part-article discusses reasons why some projects fail to result in properly accessible products. Last week we discussed the first three of seven accessibility mistakes I’ve encountered in my work, namely:

This week we’ll wrap up with four more scenarios to avoid and how. If budgets or client relationships constrain you, these ideas might at least inspire you to nudge the client in the direction of user-centric development or provide ammunition in meetings.

The Seven Accessibility Mistakes: 4-7

Mistake #4: Sharing problems with the visitor

You want to protect your site from comment spam, e-mail spoofing, and content theft. But why should visitors bear the burden, and have to enter things they see—or cannot see—in images to submit an inquiry, when it really does nothing for their personal protection? Anything computer generated is hackable by a computer given enough time and dedication—even supposedly hack-proof CAPTCHAs.

Why should your visitors have to go through a multi-step sign-up process to ask you a question? It’s your problem when you get spammed—not theirs. Yes, it does frustrate the occasional prankster and gives you a chance to point out help devices such as your FAQ section, but it also means the visitors who really need to contact you have to go through a lot more steps than they should have to. How many times have you hung up the telephone in frustration after listening to all the options of an automated system?

It is most important to offer visitors a way to communicate—it shows that you have an open ear for concerns and problems. It also covers your lower backside if someone claims there was no way to communicate with you. In some countries, legal requirements even enforce a simple way to communicate on every page of the site. Every German Web site is required to have an “Impressum,” or list of ways to contact the company.

Another concern I hear a lot is about protecting graphics and text from being downloaded. As soon as it is on the Web, clever thieves will be able to get to it. Right-click–prevention scripts, images overlaid with transparent GIFs, and looped Flash movies are not a real security measure. You only make it harder for visitors who might need that right-click menu or have no Flash installed.

What does this mean for development?

Mistake #5: Trying to solve problems outside our area of experience

It is tempting to use client-side scripting techniques like JavaScript to work around user agent shortcomings. One tool that is constantly being discussed is font-resizing widgets on the page. They are impressive in client presentations and clients will contact you because their competitors use them on their site (I had that a lot with local councils).

Font-sizing widgets are usually graphic buttons labeled A, A-, A+, and A++ or small font, medium font and large font. The most ironic ones don’t grow with the browser font but use 10×10 pixel images with light gray type on lighter gray background. How can a person who needs large texts on the page ever find those?

Others depend on scripting instead of using a backend solution with a script. You can make it work for all and change the fonts without a page reload for scripting-enabled user agents quite easily.

In any case, all of these simulate what systems outside your Web site should and already do better. Larger type is not a requirement of the site—it involves the whole operating system of the computer and is the problem of operating system and browser vendors.

The more we hack around issues of bad user agents, the fewer users will be inclined to replace them with better ones. A Web site with reasonably sized text and no fixed font size can be resized by the visitor using the controls the browser comes with. If a browser’s controls are hidden in the browser basement behind a door that says “Beware of the Leopard,” then visitors who really need larger fonts are probably not using that browser or they have found other ways around the problem. If you really want to help people, explain how they can resize fonts in different browsers on your accessibility statement page. You have enough to worry about with your site; don’t try to better other people’s products on top of that. Browser design is a totally different can of worms.

What does this mean for development?

Mistake #6: Hiding or overriding accessibility/usability enhancements

There are not many custom accessibility enhancements that change the visual outcome of the site drastically, and sometimes there is no need for those at all. One possibly necessary enhancement that causes furious discussions on boards and mailing lists is “skip links.”

These links help visitors skip over repetitive sections of the page—like those 30 links before the first line of content. They are very handy for blind users, but also help those who are dependent on keyboard access or surf on a small-screen device such as a cellphone or handheld PC.

So what is the harm in a “Skip to content” link, in smaller type and aligned to the right instead of hidden with CSS? Even more than a WAI-AAA compliance banner in the footer of the page, it shows that your clients do care about the needs of their visitors.

The same applies to fieldsets, legends, labels and the highlight border some browsers add around the current link. Yes, they do not necessarily look sexy, but they serve a purpose. Fieldsets allow any user to easily grasp that the contained fields are a logical unit.

Links have different states, and it makes a lot of sense that we define different visuals for these states. I always wondered what the active state was for, and assumed it was only visible for a moment until the linked page loaded or my script kicked in to trigger the appropriate action. What I didn’t know was that user agents set the active state to the last visited link when you hit the back button of your browser or press the equivalent keyboard shortcut. Makes sense, doesn’t it?

What does this mean for development?

Mistake #7: Catering to your client—not their clients

The times of the client knowing nothing whatsoever about the Web and believing anything we say are, sadly enough, over. Years of software vendors, magazines, hobby Web developers or relatives telling our clients that Web design is as easy as clicking a mouse have made our job a lot harder than it should be.

Clients love visuals and are more likely to be taken in by a smooth transitioning dropdown menu than a wonderfully organized site map with content examples that succinctly help the visitor to find what he is looking for in the shortest possible time.

Clients also are not as likely to spend a lot of cash these days, and want tangible results as soon as possible. Workshops, training, information architecture sessions, usability card-sorting exercises and competitive analyses are all things that decrease the amount of time spent developing, since you do not code anything that hasn’t been properly thought through. Sadly, these activities don’t produce anything that is really “there” and are therefore hard to sell or allocate hours of the already short time budget on. The speed of the Web seems to give the impression that developing for it should be as fast as using it. Some clients think that putting together a presentation that looks like a Web application is half the job done.

It is very tempting to just give in and cut as many corners as possible to make the client happy. If the client is only using Internet Explorer, why bother testing for other browsers? If the time and money budget is already strained, why not ditch the support for non-JavaScript users in the Web app? After all, other sites do it, too!

The sad fact is that it works, the client is happy, there is nearly no negative feedback from visitors and you can keep within time and budget. A full financial success. But the users of the product deserve better. And they seem to be a forgiving bunch, but the ones you inconvenienced are not complaining—just leaving.

This is the trickiest mistake to avoid, and I cannot give you a solution for it. The clients are much closer to us than the end users are. What we need is examples of where user-focused development brought in lots more money and made a company grow immensely without bursting apart at the end of the growth period. If you have success stories like that, by all means, share!

What does this mean for development?

Got something to say?

Share your comments  with other professionals (0 comments)

Related Topics: Accessibility


Christian Heilmann is a contributing writer for Digital Web Magazine. Most of his publications are written on the underground travelling through London, as there is simply nothing else to do there. One day he'd like to hand out his own book to others trapped there.

Media Temple

via Ad Packs