I once inquired about a company's expense report process, which used a Microsoft® Word document instead of a more generic format. The document contained no special formatting, so I wondered why the designers chose not to use plain text. It would have been accessible to a much broader base of users, after all. When I learned why the designers chose Word I was flabbergasted: They believed that if they didn't use it, all the Word users would be unable to access the form! Obviously, they had to support the majority of users, even if that meant leaving a smaller percentage out in the cold.

The hidden premise in this thinking -- that accessibility is somehow inaccessible to regular users -- is surprisingly common. It's also incredibly frustrating to Web usability advocates like myself, only in part because it's completely fallacious. (Since when are Word users unable to read plain text?)

Being all fired up about Web usability often means caring passionately about something that most people don't even notice. The majority of Internet users access their favorite Web sites and applications via Internet Explorer, on Windows®, with JavaScript and ActiveX enabled and all the most recent plug-ins installed. So who cares about a few outliers?

This month I offer concrete reasons why all of us should think more about accessibility and usability issues in Web design. As it turns out, incorporating accessibility features into your applications isn't hard, and it makes good business sense to boot.

Usability and accessibility

The concepts of usability and accessibility are often closely linked. The distinction is that accessibility concerns tend to affect specific users, whereas usability concerns affect everybody. The overlap between the two concerns is substantial. A menu system based on dynamically loaded images and JavaScript could be annoying and buggy to someone on a desktop, and completely unusable to someone on a cell phone. In general, usability concerns affect more people, but accessibility concerns tend to have a greater impact.

Designing for accessibility is considered challenging because it requires some awareness of the limitations affecting a range of systems, or the needs of users with disabilities. In fact, it is often possible to address accessibility indirectly, by using standards that support and leverage assistive technologies. HTML provides a number of tools for writing accessible pages, including alt tags and client-side image maps that can be rendered by a text client. Adding alt tags to your images is an easy way to make your Web site more accessible. You don't need to know why a given user on a given client system can't see your images; you simply plug in the tag and add a quick description of the image, then let the computers figure out the details.

Usability and accessibility are important, and will become more so, not less, as Web sites become increasingly textured and dynamic. The key to becoming aware of these issues is to look beyond your native system, and to consider seriously the range of physical abilities affecting Web users. You may start out with a page that looks good on your desktop, but test it out on other, preferably older platforms. Invite a novice user to navigate your Web site, and then try doing it yourself using one or more of the assistive technologies available (see Resources for a listing). When you encounter problems, don't fall back on that old defense: "But they used it wrong." If they used it wrong it's because your Web site isn't as intuitive as it could be. Make it better!

Back to top

Challenges to accessibility

Some Web designers and developers are simply unaware of accessibility. People who build Web sites tend to be computer savvy, after all, and sometimes have a hard time relating to the concerns of novice or less adept users. It's fair to say that most Web designers are visually inclined, and do not naturally approach the Internet as a non-visual medium. Web designers also tend to work on latest-model machines with big, full-color displays, extended media hard drives, and all the latest plug-ins at their fingertips. Some are only vaguely aware that certain systems, to this day, cannot play Flash animations.

Even Web designers who are aware of accessibility often choose not to implement accessibility features because they equate them with ugly Web design. This makes sense because many accessibility advocates are design challenged, or simply uninterested in creating beautiful Web pages. (I should know; I suffer from both of these weaknesses.)

Many Web designers believe that they can either build dreary Web sites accessible to anyone, or beautiful ones that work only under certain rarified conditions -- say, a no longer supported version of Internet Explorer, on a 1024x768 bit display set to 16-bit color. More subtly, they often equate accessibility with a linear trade-off: More accessibility implies less prettiness, more prettiness implies less accessibility.

In fact, it is possible to create Web sites that are both attractive and accessible. There is no reason to sacrifice usability for looks, or vice versa. What is missing is not technical possibility, it's passion.

Back to top

Why you should care

There are two basic reasons to care about accessibility. First, it makes good business sense. Second, it is socially responsible. Fortunately, accessibility features are fairly inexpensive to implement, so you can be socially responsible, business smart, and grow your bottom line all at once.

The business case for caring about accessibility boils down to three measurable benefits:

• Greater visibility
• Wider audience
• Increased user satisfaction

It's a little known fact that accessible Web sites tend to gather more search engine views, mainly because they offer a text-based interface. Many search engine spiders ignore obfuscated links. They won't click on your Flash-animated buttons, and they may not even bother to explore your frames. Search engines don't grasp (or grab) multimedia content. But they will find your accessible text links. Furthermore, the size of your audience influences the number of people who will link to you. The more accessible your Web site is, and the more search engine views it gets, the more users it is likely to attract. Ensuring your site is accessible to users with physical disabilities, on a broad range of machines, devices, and browsers, will increase user satisfaction. The sites I come back to most are the ones I can access using my PDA; they're also the ones I tend to think of when I want to link to something.

The benefits of being socially responsible are less measurable, but are nonetheless an increasingly important business concern.

Back to top

The case for social responsibility

You do not design Web pages in a vacuum; you design them to be used by people. As it happens, some people have a hard time accessing Web pages -- people whose only Internet access comes through a public library, for instance, or whose vision doesn't allow them to see small text or graphics. Studies indicate that more than 160 million visually impaired people worldwide would benefit from greater adoption of accessibility standards, and that more than 14 million Americans use public libraries to access the Internet.

Even knowing those numbers (just two among many), it's hard to account for all the people who can't actually see your Web pages, or who have left unsatisfied because they couldn't access the information they needed. You account for the users who contact your help desk or write in to request new features; not the ones who don't. (I once jokingly tried to remedy this by adding a note to some of my Web pages that said "Please contact our Webmaster if you can't see this page!" Needless to say, no one wrote in.)

On the other hand, you'll never know how many users you would gain by adopting accessibility standards until you do it. As a Web developer, you should want your work to be accessible to as many users as possible. You put a lot of time and effort into improving the aspects of your pages that matter to you -- things like appearance, layout, content, and navigation -- but a flashy Web page is a waste of bandwidth if no one can use it. Adding accessibility and usability to the list of things you care about, passionately, will make your site even better, from both a design perspective and a socially responsible one.

Back to top

Designing for usability

If you're a Web designer you may think it's your job to concentrate on layout, and leave the technical back-end to developers. In fact, it's a good idea to cultivate at least a basic familiarity with the technology you're relying on. You should know what HTML tags are and how they work in your pages. If you don't understand what you're doing, your users will be able to tell. Learn Web development terminology at least well enough to follow what more-technical developers are saying. Similarly, if your background is primarily technical and you're doing Web design, learn enough about design principles and terminology to follow a conversation. Design problems are much easier to resolve when all the participants can at least communicate.

Even if you design a lot of Web sites, make it a point to know who the target audience is for every project you do. If you decide to restrict a site's audience to "only people with IE 7" or "only people with Flash 8," you should be able to make a good case for that decision. When you articulate the reasons it may turn out that they're not as sound as you thought. Consider what would happen if you told your client that you were deliberating restricting the site's audience for aesthetic reasons. You should also know how technical your audience is. For the vast majority of Web sites, the answer is "not very," and you should design accordingly.

When you're looking at a Web page, you should know how it will appear in a text-only browser. Think about all the users who won't be able to see the page the way you designed it, and why. Try using a speech synthesizer to access your pages. If you think pages with sound effects are annoying to sighted users, just think how much more frustrating they would be to someone relying on a speech tool to hear the text on a page. It is easy to overlook this sort of thing if you don't know that millions of users view the Web through browsers that use speech synthesis instead of visual display. (See Resources to learn more about tools you can use to evaluate the accessibility of your Web pages.)

Back to top

Usability evangelism

Sometimes, what it takes to get an institution committed to a new course of action is simply for one person to make it a priority. If no one cares strongly about usability it's not going to happen. Few Web sites are as awful as those driven by a mandated checklist. Such formalized requirements ultimately miss the point. I once came across a usability standard that mandated JavaScript pop-ups to warn people when they were leaving the set of fully accessible pages. As a standard, it was incoherent at best: many of the people who need fully accessible pages don't have functional JavaScript, and many more might find that the implementation actually prevented them from following links!

If you care passionately about usability and accessibility, and you want your organization's Web site to be usable, you will have to convince people it's important. People who don't think about usability aren't going to suddenly start thinking about it because the boss sends out a memo. So make the case for usability. It starts with you.

Back to top

In conclusion

Caring about usability is what got The cranky user series started some years ago, and I am still passionate about it today. I pay attention to usability in my own work and I let people know (usually politely) when I cannot access their Web site. I think usability evangelism is important. Every time I find out that a person I've known online for years is blind, or is struggling along on an 8-year-old computer, I am reminded again of just how important it is.

This week's action item: Add alt attributes to every image that contributes data to your Web pages. Then try using a free tool like HTML Tidy or the W3C Markup Validation Service to test the accessibility of your Web site.

Resources

Learn

• "The cranky user: How not to make your site accessible" (Peter Seebach, developerWorks, March 2001): A tongue-in-cheek look at all the ways to prevent users from accessing your Web site.
  
  
• "Firefox: An open source accessibility success story" (Aaron Leventhal, IBM Accessibility Center, October 2006): A case study in how business entities can support accessibility.
  
  
• "Software Accessibility -- Where Are We Today?" (The Mozilla Accessibility Project): A history of software accessibility. Includes an overview of assistive technologies and development best practices.
  
  
• "AJAX Accessibility Overview" (Becky Gibson, IBM Accessibility Center, April 2006): An overview of accessibility concerns related to Ajax development. Includes best practices.
  
  
• "Search engine optimization basics, Part 1: Improve your standing in search engines" (L. Jennette Banks, developerWorks, February 2006): An in-depth study of SEO techniques, including where they overlap with accessibility and usability concerns.
  
  
• "IBM helps blind 'see' web video" (Geoff Adams-Spink, BBC News Web site, March 2007): Learn more about the open source multimedia browser for the visually impaired. The A-Browser is still under development by IBM.
  
  
• "Public Libraries and the Internet 2006: Study Results and Findings" (John Carlo Bertot, Charles R. McClure, Paul T. Jaeger, Ryan J.; Information Use Management and Policy Institute, September 2006): Presents findings of a national study on Internet use and public library access.
  
  
• The W3C Web accessibility initiative: Includes resources for understanding accessibility, validating the accessibility of your Web pages, and developing a business case for accessibility.
  
  
• Web Content Accessibility Guidelines: A must-read for Web designers and developers.
  
  
• IBM's Human Ability and Accessibility Center: Includes a library of resources for developing accessible applications using the Java platform and other Web development technologies.
  
  
• "developerWorks Web technology zone: Resources for Web 2.0, Ajax, wikis, PHP, mashups, and other Web projects.
  
  

Get products and technologies

• The W3C Markup Validation Service: A quick and easy way to check for missing alt attributes in your Web pages.
  
  
• Alternative Web Browsing: The W3C's listing of assistive technologies for Web browsing.
  
  
• Web Design Group HTML Validator: A somewhat friendlier alternative to the W3C validator. Don't be alarmed if your page generates a lot of output -- use Ctrl-F (find in page) and search for "alt."
  
  
• HTML Tidy: This validation program isn't as easy as the others -- you will have to download it. See the FAQ for help getting started.
  
  

Discuss

• developerWorks blogs: Get involved in the developerWorks community!
  
  

About the author

Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though.

Rate this article

Comments

Back to top

Table of contents

• Usability and accessibility
• Challenges to accessibility
• Why you should care
• The case for social responsibility
• Designing for usability
• Usability evangelism
• In conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Create rich Internet applications using WebSphere Portal Express Web 2.0 technologies.

---

• Try: WebSphere Portal Express
• Article: Get started using Ajax and WebSphere Portal Express
• Tutorial: Quickly build a an Ajax-enabled WebSphere Portal Express Web application
• Demo: Architecture, design, and construction using the IBM Rational Software Delivery Platform: AJAX
• Buy: WebSphere Portal Express

Dig deeper into Web development on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers