Accessibility From The Ground Up

Accessibility From The Ground Up

Got something to say?

Share your comments on this topic with other web professionals

In: Articles

By Matt May

Published on January 20, 2005

You’ve seen it at all the design conferences. It’s showing up on contracts and RFPs. They’re asking for it on your résumé. This accessibility thing sure is catching on. And it’s ready for prime time.

Yes, Web accessibility is growing up. Web Content Accessibility Guidelines 1.0 was released over five years ago, in May 1999. This year, the W3C Web Accessibility Initiative will release Web Content Accessibility Guidelines 2.0. WCAG is the international standard for Web accessibility, and the latest version contains plenty of guidance on how to produce modern, usable, and (dare I say it?) attractive Web sites.

I have to share the misconceptions I hear all the time about accessibility:

“It’s too restrictive on the design process, it adds too much time in development, and people with disabilities don’t come to my site, anyway!”

The answer, of course, is: “If you build it, they will come.”

And following accessible design practices as a part of everyday design ensures that you will reach more users, both with and without disabilities.

There are lots of reasons to use accessible design practices in every project. One is that it’s simply good design. Sites with consistent design and code and that adhere to Web standards are not only easier to maintain, they’re easier to use. Adherence to Web standards is not that hard, and comes with a number of ancillary benefits to authors, like search engine optimization and easy transformation.

Another argument is that it’s really not too much to ask. At its most basic, accessibility asks for text replacements for non-text content, semantic code, and a clean, understandable interface. This is hardly the ordeal many make it out to be, and the burden is even lighter when authors take accessibility concerns into consideration early on in the development process.

It’s also the law in a growing number of jurisdictions. Americans know about Section 508, which applies to federal government projects, and has been adopted in some form by 49 of the 50 states. Section 508 is the policy of many large corporations as well.

The Americans with Disabilities Act of 1990 (ADA) may also apply; New York State Attorney General Eliot Spitzer cited the ADA in reaching a settlement with the Priceline and Ramada sites on accessibility. And the UK’s Disability Discrimination Act’s scope includes corporate Web sites. Discrimination lawsuits are no fun for anybody, so it’s important for content creators to understand the problems and solutions in Web accessibility. Here’s an overview.

Keep it simple

I’m going to start my technical advice with something that seems to have been buried in the teachings of accessibility—simplicity. If you want to reach the greatest number of users possible, it’s best to write clearly and simply and design your interfaces to be consistent from page to page. For some people, simple usability advice like this is an absolute accessibility need. Many people with cognitive disabilities can fail a task simply because it hasn’t been laid out well enough for them. And anyway, people of all abilities fail tasks that are confusing. Why should we all suffer an interface that proves itself to be unusable?

Sites should go out of their way to present a navigation mechanism that’s logical from page to page. This is the kind of thing that automated tools won’t catch, so you’ll have to keep it in mind yourself as you design. (More on automated tools later.)

Likewise, it should always be easy to find out where the main content of a document actually resides—especially when dozens or hundreds of links are between the top of the page and that content. For now, it’s still important to mark that main content block with an ID and provide a “skip nav” link. (Many of us in accessibility now prefer a better description of this link. “Jump to main content” is a good one.)

The hardest part of Web accessibility, in my opinion, is the stuff outside the angle brackets. You get your content from a dozen different sources, often with a dozen different voices. Some of it, like legal text, is irreducible. Changing it even slightly could alter it dramatically, if you were even allowed to do so. In other cases, you may win the understanding of one group of users, but lose another.

The working group that produces the WCAG has wrestled with this problem for years now. The process is similar in aesthetic respects to making sausage. The group is working hard to balance genuine user needs with the flexibility necessary to apply these guidelines to the entire Web.

Many authors have asked for precise requirements for written content, but I’m pretty sure that’s not what most authors want. We could say that all content should contain words that appear, for example, in the Voice of America Special English Word Book, a list of 1,500 common English words. Or, we could specify a reading-level test like a FOG (Frequency of Gobbledygook) or SMOG (Simple Measure of Gobbledygook) readability index.

But there are more variables in understanding content than just word selection, syllables per word or sentences per paragraph. Nobody can guarantee that every document on the Web would be more accessible if these were the requirements. And nobody knows the author’s intent better than the author.

So the group has taken the middle way. The most recent draft of WCAG 2.0 contains detailed requirements for content creation, but only at the highest level of conformance.

Still, that doesn’t let content creators off the hook. Organizations that are serious about accessibility should have a style guide in place to ensure a consistent product. Editors should look out for unnecessarily verbose or confusing copy, and work to keep it clear and simple.

And inside the angle brackets, there are some responsibilities as well. For example:

  • The language of a piece of content, and any changes within, must be marked up using the lang attribute.
  • Acronyms and abbreviations must be marked up using the acronym and abbr elements.

It’s the new style

It’s official. Cascading style sheets are good—especially when they’re used.

With CSS, users can adjust sites to suit their needs, whether they are color selection for contrast or colorblindness, or font sizes or faces for low vision or dyslexia.

Document semantics is even more important. Users of screen readers depend on HTML semantics to understand and navigate sites. In addition to the “skip nav” concept, screen readers allow users to scan the headers in a page. Using the h1 through h6 elements gives those users a tree hierarchy to navigate. Remember that headers in the margins (i.e. “links”) are still headers. Mark them up properly and set their style using CSS.

Spacers, while passé, can be benign from an accessibility perspective. However, at all times, use alt="" in your spacer images. Use no words at all to describe spacers. It sounds like a funny request, until you’ve heard a dozen sites repeating “this image is for visual layout only” a hundred or so times. I don’t recommend it. At all. Ever.

Some other tips:

  • Mark up lists as lists. Images and line breaks are not an acceptable substitute. The list-style CSS property is your friend.
  • If you’re using the b and i elements, chances are you should be using either strong and em to indicate semantic emphasis; a header element to indicate the start of a section; or CSS to indicate a purely visual flourish.

Turning the tables

Layout tables are not strictly forbidden by WCAG, but they do present accessibility problems when done poorly.

Nested tables can be a nightmare, as they can make screen readers jump around nonsensically. If you must use tables in your designs, make sure that they linearize well—that is, the content in those tables must be logical when read out as if the table wasn’t there.

It’s best to use pure CSS. Failing that, a simple table can be used as a framework with CSS defining the layout of each cell. (Note that it’s possible to make CSS that doesn’t linearize properly, though it’s usually a bit harder to do.)

Tables for data, on the other hand, are great. Some tips for good data tables:

  • Use the summary attribute of table to briefly explain the purpose of the table.
  • Use the th element for table headers. If the headers themselves are abbreviated, use the abbr attribute to expand them.
  • For complex tables, use the scope attribute on table headers to indicate what they pertain to, and the headers attribute on table cells where there isn’t an obvious correlation with a given header.


I’ve been painting a lot of this in broad strokes, but I’m going to narrow in on one specific design meme I’d like to see less of: light gray text on white, or low-contrast green or blue schemes. Yes, it’s pretty. It’s also inaccessible.

Now, you don’t have to set your foreground and background colors on opposite sides of the color wheel, but you do need to make sure that there’s good visual contrast in your content.

We’re fortunate enough that many of the color schemes that trigger colorblindness issues are ugly. But it’s important to remember that a measurable percentage of men have red-green colorblindness (deuteranopia); instructing them to click the green box for yes or the red box for no, for example, should be avoided.

Never use color alone to indicate a difference between parts of a document. The WAI site contains a list of colorblindness tools that let you see sites as people with different types of colorblindness would.

Can I use JavaScript?

Yes, you can. In fact, contrary to popular opinion, JavaScript was never “banned” by the WCAG. What WCAG 1.0 did say about JavaScript is that it must function in a device-independent manner, and pages should function properly if JavaScript is disabled. The WCAG Working Group is putting together client-side scripting techniques for WCAG 2.0.

Can I use Flash?

Again, yes, within some constraints. In order to make an accessible site with Flash, you must offer a functional equivalent (e.g., HTML navigation to cover for missing Flash nav).

Flash has accessibility-related features built in at the moment, but the client is only directly accessible on Windows. Users of other operating systems will still need an alternate interface.

Direct Flash accessibility is, for the time being, particularly difficult to achieve, since most of it is built into ActionScript. The details, right down to the tab order, need to be specified in a code window. You can find out more in Macromedia’s Flash accessibility whitepaper. If that makes you a little squeamish, you can still make your content accessible by providing a functional alternative in HTML.

I’ve been asked what I think about Scalable Inman Flash Replacement (sIFR). I think it’s a great idea, particularly for properly marked-up headers. I would recommend it over other image-replacement schemes for its relatively clean implementation and the fact that it degrades to plain text. In this case, the underlying HTML is the alternate content.

The great checker debate

Imagine this conversation with the contractor who’s building your house:

“Aren’t you going to use a level for that railing?”

“Oh, yeah, I’ll check it with the level once it’s screwed in.”

Sure, it’s good to have a tool to help you do a job, but if you’re not adequately skilled to do the task, all a tool like a level is going to do is inform you after you’re done that you did it wrong.

That’s the situation you’re in when you rely on an automated accessibility tester to do the job. If you or your team is going about designing a site blithely unaware that accessibility problems are being created, automated tools are not going to save you in the end. They’ll just confirm what you probably already know—stuff is broken.

Designers need to study the needs of accessibility and design it into their processes from the beginning. It is sufficient for most purposes to read a book or two on Web accessibility to understand the audience you’re building for, what its needs are, and how to satisfy those needs.

Nearly all of the automated tools in the market also return “manual checks.” My experience, and that of the developers of these tools, is that authors often gloss over these checks, or don’t understand what is really required. A basic grounding in the meaning and intent of these manual checks will help you to build more accessible pages—and save a lot of time.

Getting help from your vendors

And speaking of tools, unless you’re doing all of your work in Notepad, you should be asking for more from your authoring tool. The accessibility features in many authoring tools are much improved over previous versions. But the key feature request to make is for your tool to conform to the Authoring Tool Accessibility Guidelines. ATAG, as it’s called, outlines necessary features to help ensure that all content that’s produced will conform to WCAG. That is, accessibility is not only your job as an author. Web software needs to improve to ease the load.

Nowhere is this more critical than in browsers and media players. It makes much more sense to get a handful of user agents to handle accessibility features properly than to get millions of authors to try to cover for them. Ask your browsers and players of choice to conform to the User Agent Accessibility Guidelines. With content creators, authoring tools, and browsers each doing their part for accessibility, we can look forward to a better Web experience for all, regardless of disability.

Related Topics: Accessibility, Basics

Matt May is a Web accessibility specialist for the World Wide Web Consortium. He is the staff contact for the Authoring Tools Working Group, the User Agent Working Group, and the Protocols and Formats Working Group. In addition, he is a participant in the Web Content Accessibility Guidelines Working Group. That’s a lot of meetings, folks. In his 14 free minutes a week, he blogs at