 | Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
24 Apr 2007 Web usability suffers from a proliferation of browsers,
competing standards, rushed deadlines, and more. But the greatest obstacle to
usability is that too many Web developers aren't interested in it -- or even convinced that it matters. This month the cranky user offers concrete reasons why you should start prioritizing the usability and accessibility of your Web pages.
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!
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.
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.
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.
 |
Prioritizing accessibility
The W3C has made accessibility one of its top priorities, along with organizations like Microsoft, Mozilla, and IBM. Microsoft has long incorporated
accessibility features for hearing, vision, and physical dexterity into
selected software, including its Office suite and Internet Explorer.
Mozilla's Firefox 1.5 introduced accessibility features for browsing dynamic
content, and Mozilla has continued to advance accessibility with its
Accessibility Rich Internet Applications (ARIA) initiative. IBM also
prioritizes accessibility, and will soon release the open source
A-Browser, which makes multimedia content accessible to visually impaired
people. See Resources to learn more about how
these and other organizations have made accessibility an important part of their
business agenda. |
|
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.
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.
 |
Beware the WYSIWYG!
Some of the worst HTML I've seen was produced by WYSIWYG tools that
present the Web designer with a "what you see is what you get" design environment. Some tools are better than others, but the bottom line is
that users of these tools rarely have a basis for understanding the code being generated, which makes it hard to fix when something goes wrong.
WYSIWYG tools also tend to be optimized for specific browsers, so pages generated this way can look awful in any other environment. |
|
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.)
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.
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
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 page
|  |