As people’s use and awareness of the Web grows, accessibility (or “universal design”) becomes more crucial. Accessibility is determined not only by a website’s code but by its design and content, which is why accessibility, standards and usability are so connected.

Web accessibility is a vast topic and has become a field unto itself. But don’t let that scare you. Accessibility is not terribly difficult to implement. It won’t hinder aesthetics or impede interaction as some believe. It’s just a smart way to design and develop.

Let’s examine 25 important techniques for creating an accessible website.

1. Consistent Layout and Structure

To help users navigate your website quickly and easily, you should provide a consistent layout and structure. The main elements of the page—banner, navigation, sidebar—should appear in the same locations throughout the website. They should also be marked up consistently, such as with the same heading structure. This will also benefit those with cognitive impairments and those who use a screen-reader application (which processes content on the screen and reads it aloud).

2. Add Alternative Text to Images

Unfortunately, as widely known as alternative text is, it is all too often ignored or not implemented correctly. An image element’s alt attribute provides a textual description of the image. When the image cannot be seen—as would be the case with blind users, search engines, blocked images and broken links—then the “content” of the image is accessed through its alt text. Here are some best practices for alt text:

• If text is embedded in the image, add it to the alt attribute.
• Decorative images should be handled with CSS. But if one isn’t, then add the alt element but leave it empty Not only does this validate better, but it indicates to assistive technologies that the image does not contain anything meaningful.
• For some images, such as charts and artwork, longer descriptions are needed. There are multiple ways to add long descriptions, such as by adding the content inline, using a “d-link” and using the longdesc attribute (which is now barely supported).
• If a link contains only image content, then the alt text should describe the function of the link, not the image itself.

3. Use Page Headings

Page headings are a basic building block of Web pages. As mentioned, they help give a consistent structure to HTML documents. For example, the h1 element might contain the title of the page or website, and an h2 element would denote a heading on that page. This not only helps screen-reader users to navigate, but makes the page more readable for sighted users. Headings are also good for SEO (but don’t abuse them because Google will catch on and penalize you!).

Never use styling alone (e.g. bolding, increasing font size) to create headings. Always use the h1 through h6 elements, and then modify their appearance with CSS. If a user agent does not render CSS, then the headings will usually at least be displayed in a format that preserves the document’s visual structure.

4. Use Headings Properly

Headings are often implemented incorrectly as well. They are out of order, and heading levels are skipped. Think of your document as an outline. Here are some guidelines:

• Give every page only one h1 element (unless you’re using HTML5).
• Give the h1 content that is similar to the page’s title.
• Use headings in order. For example, h1 should be first, and h4 should follow h3.
• Don’t skip headings. For example, don’t jump from h2 to h4.

For more on headings and document structure, check out the article “Creating Semantic Structure” by WebAIM.

5. Skip Links

An anchor link moves the cursor from one area of the page to another, and a “skip” link is a particular type of anchor link. It very helpfully allows keyboard users to jump past large blocks of content and links, notably navigation menus. Skip links are often placed at the top of pages and point to the main content, so that users don’t have to scroll through the banner and navigation every time they arrive on a new page. Considering the number of links in today’s navigation bars, this can save a bit of time.

Never hide the skip link with the display:none CSS property, because this will make the content invisible even to screen readers. Leave it visible, but if you must hide it, then use CSS to give it a negative margin (or something similar) and then display it when the user focuses on the link. The Web Standards Project implements a great example of this technique on its website.

ARIA and HTML5 provide methods of navigation that could make skip links obsolete. But until these new technologies are more widely supported (and headings are better implemented), adding a skip link or two to the top of the page is still good practice.

6. Link Content

Because some assistive technologies show links on a separate page, the content of textual links is very important. It sounds simple but can be challenging at times. The following rules are good not only for accessibility, but for usability and SEO as well:

• A link should still be meaningful out of context;
• A text link should be unique to the page on which it appears (i.e. don’t use the same link text for different resources);
• Never use “Click here” or “More” for link text;
• Do not use a long URL for link text (screen readers will read it all out and annoy the user).

In the following text, the user must backtrack to understand where the link goes.

Not good: To learn more about the bat species, click here.

The following is more succinct and would make sense even out of context.

Much better: If you’re interested, learn more about the bat species.

7. Link Awareness

Users should always be notified if a link opens differently than normal; i.e. in something other than a Web page in the same browser window. This includes links that open in a new window and links to non-HTML files, such as PDF and video files.

There are different ways to notify users, and you should implement more than one of them with each link to accommodate different levels of disability and browser support.

You could display an icon just beside a link to a PDF file using the code below. Note that, in addition to serving as a visual cue, the icon contains an alt attribute, and the link has a title attribute that provides supplementary information:

8. Be Careful With Title Attribute

The title attribute is handy for adding supplementary information, but it is still only supplementary. When writing title text, the “tooltip,” assume that users will not always read it. Many screen readers do not recognize the title attribute by default, and most users don’t check for them. As we saw in the previous section, we can indicate that a link has an unusual target by using techniques other than the title attribute.

9. Keep the Underline

Just because you can, doesn’t mean you should. In this case, do not mess with the underline in links. The convention for denoting a textual hyperlink on the Web is underlining. Don’t remove it. The pro-underline side in this seemingly age-old debate has been gradually losing ground because of a lack of awareness about accessibility and the increasing competition to build the “best” design.

With respect to accessibility, the main reason to retain underlining is so that links remain visible to color-blind users. Even I have trouble distinguishing links from plain text when the underlining is removed and the link color does not contrast well. Consider a page with black text and dark blue or purple links; distinguishing the two, if even possible, would put quite a strain on the eyes.

One exception to the rule is for the navigation menu. Removing the underlining in it is fine as long as its function is totally obvious to the user.

Also, do not underline plain text that is not hyperlinked. If you want to emphasize the tone of a word, then use the emphasis element (em).

10. Forms

To make a Web form accessible, label its fields. Most fields are already labeled, so it’s just a matter of attaching a label element to the relevant text. Give the field a unique id, and refer to the id in the label element with the for attribute. For a text input field labeled firstname, we would use the following (the name of the field doesn’t have to match the id, although it’s easier that way):

This is an example of an “explicit” label. You could also have used an “implicit” label (i.e. without the for and id attributes), but it would be more restrictive because the form element needs to be within the contents of the label element. See the HTML labels specification for more.

Another useful technique, especially for longer forms, is to set up fieldsets with legends. A fieldset groups a form’s elements together, and the legend gives that group a name. This makes the form easier to read, navigate and, thus, complete. In the following example, the fields for the first name and last name are grouped under Name, and the address and city fields are grouped under Location:

Other recommendations:

• Use the optgroup element to group related items in a long drop-down list.
• In addition to using the label element, you can also associate a form field with a text label using ARIA with the aria-labelledby attribute.
• Always validate a form both server-side and on the front end.
• In WCAG2, implicit form labels are deprecated in favor of explicit ones.
• Keep forms as short as possible. Do not ask for information that you don’t need.
• Instructions or information that are not contained in a form-specific element might not be read if an assistive reading device is in forms mode. For example, an alert that a field is “Required” should be contained inside the form label.

11. Make All Links Accessible to Keyboard

Many people do not use a mouse. Some assistive technologies rely on keyboard input or a virtual keyboard rather than a mouse or pointing device. For this reason, links should not require a mouse to be accessed. Stick with the standard a element with an href attribute.

This might seem obvious, but look around the Web and you’ll come across instances of the wrong code before long. This is the concept behind Plain Ol’ Semantic HTML (POSH) with progressive enhancement (PE) (see section 15 of this article below: “The Three Tiers”). Implementing POSH and PE together is the best way to ensure that links are accessible to the keyboard (they bring other benefits, too).

To enhance the behavior of a link using this method, add a hook—such as a class or id—to the link; that hook would then be accessed unobtrusively with JavaScript via the DOM. This way, the HTML remains semantic, light and clean. Here are a few more tips to follow:

• Do not use the double-click handler (onDblClick) because keyboards cannot execute this behavior.
• If you use the onMouseOver and onMouseOut JavaScript handlers, also use onFocus and onBlur to accommodate keyboards.
• If you must use JavaScript, then give the link a tabindex value of -1 to insert it in the tab order. A tabindex of 0 makes even divs accessible to the keyboard.

12. Show Link Focus

Highlight links (visually) when they are in focus. This indicates to sighted keyboard users where they are on the page. Likewise, provide visual feedback on mouse hover. Never remove the default link outline in CSS—a{outline:0}—unless you replace its functionality. CNN is an excellent example of what not to do. Tab through its website and you’ll get lost very quickly; you get no visual cue of the link you are focused on. By contrast, Accessible Twitter retains the default outline and adds a distinct focus effect, even on form fields and buttons.

13. Add ARIA Landmark Roles

Accessible Rich Internet Applications (ARIA) is a relatively new W3C specification that provides a method for making modern applications accessible to assistive technologies. As a first step, try adding “landmark roles” to your documents. These are special attributes that describe sections of the page, such as content, navigation and search. This gives users of screen readers a great way to navigate (although ARIA is not fully supported in some screen reader-browser combinations). In the following example, the four landmark roles create a basic page structure:

For more on ARIA, read the great “Introduction to WAI ARIA” article on Opera’s developer website.

14. Validate Mark-Up

Valid HTML and CSS in and of itself is good for accessibility. It doesn’t have to be perfect, but validated code is the goal. While rare, invalid HTML or CSS can pose problems for assistive technology, even while appearing fine in browsers.

Here are more benefits of valid code:

• Robust Web pages are more likely to work on a variety of browsers and devices.
• Maintainable Consistently coded pages are easier to create, maintain and troubleshoot.
• Reliable Web pages render and perform more dependably.
• Supported Valid code is more likely to be supported in future versions of browsers and devices.

Bear in mind that a technically valid document does not ensure accessibility. A perfectly valid document whose semantic elements are entirely wrong will impair accessibility. Examples are: giving headings an improper structure, using blockquote to indent, and using the summary attribute in tables for layout. To validate your code, you can use the W3C’s Markup Validation Service and CSS Validation Service. Many developer toolbars, such as the Web Accessibility Toolbar by The Paciello Group, provide shortcuts to these services. ARIA and HTML5 doesn’t currently validate, but you can try the “highly experimental” Validator.nu, which I find works pretty well.

15. The Three Tiers, and Progressive Enhancement

To implement standards effectively and make a website more accessible, you must first separate content, style (or presentation) and behavior using HTML, CSS and JavaScript. These are the three tiers of front-end development. This separation also makes progressive enhancement (PE) much more feasible; PE enables websites to degrade well on older browsers and technologies.

A great example of PE is a technique called “Hijax” by Jeremy Keith, which enables a page that has AJAX to function even when JavaScript is unavailable. A great rule of thumb is, “Plan for AJAX from the start, but implement it at the end.” To learn more about Hijax, read this great presentation by Keith from back in 2006: “Hijax: Progressive Enhancement with AJAX.”

16. Use List Elements for Lists

Sounds so simple, but lists are so often not marked up right. Unordered, ordered and definition lists are great for marking up all kinds of information. Unordered lists (ul) are good for ordinary bulleted lists and navigation links. Ordered lists (ol) are basically numbered lists, used to show, say, steps in a process. When coding an unordered list, do not put bullet images inline with the content. Instead, use a properly marked-up list and then style with CSS.

Definition lists (dl) are made up of definition terms (dt) and definition data (dd). Usually, a term is assigned one or more data elements. An obvious example is a glossary: a word would be marked up as the definition term, and its definition would be the definition data. Here is a definition list showing the acronyms and full names of three mark-up languages:

Sometimes a term can have more than one definition, and vice versa. Here is a list showing the word “theater,” its alternate spelling and multiple definitions:

17. Use More Than Color to Convey Meaning

Many people have some form of vision impairment, such as color blindness. Seven percent of US men are reported to have some form of color blindness. So, you cannot use color alone to communicate meaning. Instructions like “Select the red button” will not be helpful to people who have trouble distinguishing that color. Instead, make sure that every instruction refers to a specific non-color characteristic of the target, such as its shape (e.g. octagon) or text (e.g. “Stop”). Another solution is to add a shape, such as an octagon, and perhaps a texture to the targeted item. For more information and solutions, check out We Are Colorblind.

18. Color Contrast

Related to the last point, give your design sufficient color contrast, which will help low-vision and color-blind users. WCAG 2.0 Level AAA requires a minimum contrast ratio of 7 to 1. A ratio of 4.5 to 1 or higher is recommended, which would be the AA level. These ratios are calculated from a formula based on the color luminance of foreground and background colors. Some good tools available to check color contrast are:

• Color Contrast Checker by WebAIM,
• CSS Analyser by Juicy Studio,
• Color Contrast Comparison by Joe Dolson,
• Graybit.com, which converts entire Web pages to grayscale,
• Colorblind Web Page Filter, where you can check for a variety of color-blindness types.

19. Mark Up Data Tables Correctly

Make your data tables accessible to all by coding them properly. To start, give the table a caption element or a summary attribute—ideally both. The caption element will be the title of your table. The summary attribute describes the content and structure of the table and is usually accessed only by users of screen reader (its relevance to HTML5 is currently being debated.)

Next, mark up the cells for the table’s headers appropriately, with th rather than the usual td. Then, insert the scope attribute into the header’s cells. If the header is in the top row and targets the cells below, then use the value col (for “column”). If the header is in the left column and targets the cells to the right, then use row. Here’s an excellent example, derived from the article “Bring on the Tables”:

In tables with complex data (i.e. ones with more than one header level), add headers and id attributes to the table cells. For more on this technique, visit the Complex Data Tables section over at Web Usability.

Also, even though laying out a page or section with a table does not directly affect accessibility, using pure CSS is best. Reserve tables for tabular data (as they were intended).

20. Make Changes to Content Clear

Be sure to alert users when content changes dynamically on the page. ARIA Live Regions is a relatively new technology that handles this task for users of screen reader, and rather easily, too. Insert the aria-live attribute in the element for the content that will be updated. Value options are off, polite and assertive. The default value is off, so be sure to set this value explicitly.

You could notify sighted users of changes by fading the background of the updated content or by overlaying an alert using JavaScript.

In any case, warn users before automatically reloading the page or forwarding them to another page.

21. Now, About That Flash…

According to users of screen reader, Flash is one of most inaccessible technologies on the Web. Adobe has worked hard to make it possible to create accessible Flash content, but frankly speaking, developers rarely take advantage of it in practice.

Use Flash sparingly, and make every effort to make the Flash content you do have accessible. If that’s not possible, then provide an alternate way to access the content.

The entertaining piece “Assistive Technology Boogie” (link is to Flash file itself), by Inclusive Technology, is a great example of accessible Flash. It is accessible by keyboard, it provides captions, and it even has an audio description.

22. Provide Transcriptions

Give all audio a textual accompaniment to help users who are deaf or hard of hearing. Transcripts have other benefits, too: they give all users a choice on how to access content. A user might not have audio capability on their device, or their speakers or headphones might be broken. They could be in a library or workplace where sound would be disruptive. Not to mention, transcripts are great for SEO.

There are several methods of marking up a transcript. One widely used method is to use a definition list. The speaker’s name is marked as the definition term, and the speaker’s words are marked as the definition data.

For HTML5, a dialog element was created but then unfortunately removed. The specification currently suggests using paragraph elements to mark up a conversation.

23. Add Captions

You should provide timed captions on video and multimedia content for the same reasons you should provide transcriptions. Here are a few resources to get you started:

• Web Captioning Overview by WebAIM,
• Providing Closed Captions by the W3C,
• Captioning Best Practices by the University of Wisconsin.

24. Appropriate Language

“Appropriate” language usually means simple language. If saying “funny” would be just as effective as saying “jocular,” then stick with the former. Simple language helps both people with cognitive impairments and non-native speakers. Here are some tips:

• Write short sentences;
• Write short paragraphs;
• Favor the active over the passive voice;
• Avoid jargon, slang and idioms;
• Define technical terms;
• Provide the full names of uncommon acronyms and abbreviations.

Of course, for websites dealing with technical or complicated subject matter—like, oh, say, rocket science—“appropriate” becomes a more apt goal than “simple.” To learn more, check out the excellent SlideShare presentation “Web Accessibility for Writers,” by 4 Syllables.

25. Test Through Multiple Methods

Use multiple methods to test a website for accessibility. And don’t rely solely on automated tools, because many of the things you should be checking are subjective in nature, such as language, tab order and link text. The best way to test a website is to have an experienced user of assistive technology review it.

Here are just a few of the things to cover:

• Unplug your mouse, and go through the website with only a keyboard;
• Run at least two automated tests, such as WAVE, Cynthia Says and A-Prompt;
• Apply the color contrast tools mentioned earlier;
• View the content without CSS, and without JavaScript;
• Check the heading structure;
• Go through the website on many browsers and devices;
• Take advantage of one of the Web accessibility toolbars;
• Read the content with an eye to color-specific language, directional language (“above,” “to the left”), etc.

If you fell as if all of the above is a bit overwhelming then there is another alternative. InMotion can help you design your site. It’s a very easy process. First you’ll be interviewed, so that they get a feeling for what you want, and when they have a finished product to show they’ll send you a draft. If you’re happy with what they have done, they will it set it live for you. If you don’t like it they will tweak it till you’re satisfied. It doesn’t get much easier than that.

About the Author

Dennis E. Lembree is an accomplished Web developer who has worked for a variety of companies, including Ford, Google, Disney and RIM. He is the author of Web Axe, a podcast and blog focused on Web accessibility. Mr. Lembree is also the author of the award-winning Accessible Twitter Web application. He has presented at several conferences, including Accessing Higher Ground, INDATA Assistive Technology Conference and the 25th Annual International Technology & Persons With Disabilities Conference. Mr. Lembree is originally from southeastern Michigan and has also lived in Orlando, Florida. He now resides in Cupertino, California, with his wife and their two boys.

by Dennis E. Lembree
www.webhostingsearch.com, Jan 17, 2011