| home / programming / usability / 1 |   [previous] |
|
|
|
First, a little Web history.
In the beginning, everything was text. When the first visual browsers arrived, designers found that unlike desktop publishing, which gave them control of everything, HTML—which was really only intended to display research papers— gave them almost no control over anything. Commands for styling text were crude, and it was very hard to position things precisely on a page. And even if you could, pages often looked completely different when viewed in different browsers.
To wrestle back some control, designers and developers started using tables to control layout. For years, the only way to control the position of things on a Web page was to put them in tables... and tables within tables. Most pages ended up seeming like a series of Russian nesting dolls.
Unfortunately, this didn’t work well with early screen readers, which tended to read rather slavishly line-by-line from left to right, like this:
They also started using various HTML commands in ways they weren’t meant to be used, to try to get more control over text styling. It was a messy world of hacks, held together with chewing gum.
Fortunately, beginning in 1998 some very determined people got fed up with this state of affairs, and decided to convince browser manufacturers to support Web standards that would give designers a consistent target. A group of designers calling themselves The Web Standards Project employed a brilliant form of nonviolent resistance: They simply stopped making their own sites backwardly compatible with browsers that didn’t support standards like CSS, and encouraged others to do the same.
Several year later, CSS Zen Garden9 (a single HTML page that looked completely different depending on which of the many designer-contributed style sheets you applied to it) demonstrated that you could create beautiful, sophisticated designs with CSS.
Cascading Style Sheets are now so well supported by most browsers that it doesn’t make any sense to create a site without them, because the advantages are enormous:
> Infinitely greater control of formatting.
> Flexibility. A single change in a style sheet can change the appearance of an entire site, or automatically generate useful variations like printer-friendly pages.
> Consistency among browsers.Workarounds and hacks are still required to ensure that your CSS works across all browers, but these will fall away as brower makers continue to improve their CSS support.
And implementing CSS will make it easy for you to do two things that will greatly improve your site’s accessibility:
> Serialize your content. Unlike table-based layout, with CSS you can put your content in sequential order in the source file—which is how a screen reader user will hear it—and still position things where you want them on the page.
> Allow your text to resize. CSS makes it easy to make your text resizable, which is enormously helpful for low-vision users (and people old enough to need bifocals).
Probably the fastest way to learn CSS is to get someone who specializes in it to do a “markover” for you—recoding a few of your site’s page templates to use CSS— and learn by watching them do it. When you’re ready, there are also a number of good books on CSS, especially the ones by Eric Meyer.
Now you’re ready to do what most people think of as Web accessibility: implementing specific changes in your HTML code.
As of right now, these are probably the most important things to do:
> Add appropriate alt text to every image. Add an alt attribute for images that screen readers should ignore, and add helpful, descriptive text for the rest. All of the Web accessibility books have very good explanations of how to do this.
> Make your forms work with screen readers. This largely boils down to using the HTML label element to associate the fields with their prompts, so people know what they’re supposed to enter.
> Create a “Skip to Main Content” link at the beginning of each page. Imagine having to spend 20 seconds (or a minute, or two) listening to the global navigation at the top of every page before you could look at the content, and you’ll understand why this is important.
> Make all content accessible by keyboard. Remember, not everyone can use a mouse.
> Don’t use JavaScript without a good reason. Some adaptive technologies don’t support it very well yet.
> Use client-side (not server-side) image maps. Alt tags don’t work with server-side image maps.
That’s it. You’ll probably learn how to do a lot more as you go along, but even if you only do what I’ve covered here, you’ll be doing a pretty good job.Hopefully in five years I’ll be able to just remove this chapter and use the space for something else because the developer tools, browsers, screen readers, and guidelines will all have matured and will be integrated to the point where people can build accessible sites without thinking about it.
Excerpted from "Don't Make Me Think, Second Edition: A Common Sense Approach to Web Usability" by Steve Krug. Copyright © 2006. Used with the permission of Pearson Education, Inc. and New Riders.
| home / programming / usability / 1 | [previous] |
The Network for Technology Professionals
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers
|
Video: How System Center Helps Reduce IT Costs IBM Cloud Computing for Developers Virtual Event, April 6-8 |
Microsoft Video: OCS and Exchange: Platform Futures MORE WEBCASTS, PODCASTS, AND VIDEOS |
Created: March 27, 2003
Revised: November 22, 2005
URL: http://webreference.com/programming/usability/1
