Seven Accessibility Mistakes (Part 2)

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:

• Mistake #1: Believing in products without putting them to the test. It’s no fun realizing halfway through development that the CMS does not really help create clean markup, or the framework in use spits out controls that are only usable with a mouse.
• Mistake #2: Taking too much responsibility. Sometimes we give the client the impression that all he has to do to create an accessible product is believe in us. We should help the client understand that when it comes to maintaining the product, accessibility is as much his responsibility as it is ours.
• Mistake #3: Planning only for the worst-case scenario. Too often we see accessibility as only designing for the lowest common denominator, keeping alive the myth that accessible products have to be ugly and cumbersome.

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?

• Don’t promise any JavaScript- or CSS-based protection measure—there is no such thing. They are annoying for normal visitors and a minor discomfort for malicious attackers.
• Coach the clients on the importance of communication channels. A Web site is first of all about delivering content, but also an invitation to communicate. The amount of inquiries turning into good leads is a measure of your success as a business partner.
• Find backend solutions for spam issues instead of making it harder for the visitors to contact your client.

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?

• Don’t get too excited about widgets and the power to change the user agent via client-side technologies. Remember that there are a lot of different people and user agents out there.
• 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. If you want to help visitors who are not that Web-savvy, add a help section that explains how to change the font size. However, don’t expect too many people to read it—those with a real need to have bigger text had to get to your site somehow, and already know how.
• If you add your own widgets, make them bulletproof. They should work without scripting and resize with the browser settings.
• If you want to give visitors a chance to customize your site, do it properly: Offer ways to change the layout, add and delete content sections, move navigation around and provide other features portals and intranets offer.
• Be aware that quick fixes around inconsistencies or common browser problems today are here to last tomorrow and the day after that. It seems that developers are quick to add, but reluctant to remove them. How many times do you encounter “Click to bookmark” links that only work in MSIE?

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?

• Make sure that any accessibility enhancement you add can be used by those who need it. Skip links are not just for screen reader users.
• 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 and get rid of those “ugly borders on hover,” 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.

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?

• Try not to buckle to every idea the client wants implemented. You are not a butler, but an expert hired to do a job properly.
• Make sure you know the examples that “wow” the clients and have material at hand that explains why it might not be a good idea to implement them in their product.
• Don’t act impulsively. Explain that every change needs testing and the input of other people in the company—business analysts, technical architects, designers, Web developers, etc. Provide budgets and timeframes for the implementation work before going for it.
• Keep the number of people talking directly to the client to the bare minimum. Ideally there should be one dedicated point-of-contact delegating tasks to the team. With too many lines of communication open, someone will promise to implement a change without consulting the team, or underestimate the real amount of work the change will cause. Children know this trick—if Dad says no, try Mom!
• Start a catalogue of success stories of user-centered design for all your projects. You might be able to implement one bit in each of those and assemble a good portfolio to show new prospects in the future.

Related Topics: Accessibility