Accessible By Design

In: Articles

By Anitra Pavka

Published on April 10, 2002

“Web accessibility” is a hot topic today. You may also be familiar with other phrases like the W3C Web Accessibility Inititiative (WAI) or U.S. Section 508 guidelines. Many countries have Web accessibility guidelines that apply to their government sites. Now private companies are also realizing the benefits of creating accessible technology. The demand for accessible sites is growing, but Web workers, like you, are often unclear how to make sites more accessible. Designing an accessible site isn’t necessarily harder, but it involves unique limitations that make you approach design from a different perspective.

Good Web design is accessible Web design. Despite popular belief, the two do not have to be at opposite ends of an aesthetics spectrum. Accessible sites can appeal to all users. They aren’t just ALT-tagged images with black text on a white background. All design faces constraints. For Web design, the ability to access a page’s content is a fundamental limitation. The basic design of a site can enhance the user experience for disabled users or make the site inherently inaccessible to them.

Embracing Diversity

The variety of user disabilities is easy to overlook. Visual disabilities are only one type of disability. While ALT attributes are essential for a blind person accessing a site, captions are critical to a deaf user. Even the category of visual disabilities has unique sub-groups, such as colorblindness, cataracts, and long sightedness. Other major categories of disabilities include: cognitive, mobility, and hearing. Some disabilities, such as speech, won’t affect a person’s ability to use the Web. Users may have varying degrees of disabilities or even multiple disabilities. Disabilities are as unique as the people who have them.

An accessible Web embraces diversity. Unless you’re working on an intranet, your audience is the world. Marketers may have a targeted audience in mind, but anyone may attempt to use your site. A user can be blind, deaf, or just trying to use their cellular phone to access a site while in rush-hour traffic.

Accessible sites accommodate more than users with disabilities. Wireless handheld devices are becoming an increasingly popular way to access the Web. Many offices save money by scrimping on hardware. They may exclude external speakers or buy low-end graphics cards that render color and graphics poorly. Audio on your site may get lost because of noisy surroundings or a lack of speakers. Environmental and device limitations must be considered during design.

How to Create Accessible Documents

The keys to accessible Web design are simplicity, relativity, and communication.

Equivalents

The ALT attribute for images <IMG> is usually necessary, but keep a few things in mind when you use it. The description should be as concise and complete as possible. Put the most important words in the first part of the description. If the image is a link, it may be helpful to indicate what action will happen if the user selects it. If the description exceeds approximately ten words, consider linking to a longer description.

The “longdesc” attribute is intended to let you link to a longer description of an image, but it isn’t well supported. Instead, the current convention is to provide a “d” link. After the image tag, insert a link with the letter “d” as the text. Link it to a separate page that provides the full description of the image. This is especially important for complex informational images like charts or graphs.

Don’t forget to add ALT attributes to things sighted users may easily overlook. Text that’s actually an image is probably the worst culprit. These graphics are often used as a header to display special text effects. Put all the text displayed in the image into an ALT attribute or into a “d” link, if the text is too long.

For purely decorative or spacer graphics, use an “empty” ALT attribute. Do NOT add a space between the quotation marks: ALT=””. The empty attribute indicates that there is no meaning or content associated with the image. Since the value is null, the browser should not render it. If you add a space between the quotation marks, some browsers may render the space in an odd manner. For example, a tool tip with [] may appear.

Provide equivalents for other elements that users may not be able to access. For example, add captions or transcripts for audio elements. Supply useful, alternate content if scripts and applets are turned off or unusable. List redundant text links if you use server-side image maps.

Navigation and Links

Use consistent navigation across your site. Consistency is key to both accessibility and usability.

Avoid using image-based navigation or links. Text links are easier to create, maintain, and are more accessible. Especially avoid image maps. Instead, try slicing the graphic. This way, you can easily add ALT attributes and links to individual pieces of the image. If image maps are unavoidable, use client-side ones, if possible. Remember to add descriptive link names to the hotspots. If you must use server-side image maps, you’ll have to provide redundant text links, preferably immediately after the image map. Server-side image maps may be inaccessible for many users.

Add a space and a printable, non-link character between adjacent links. This helps users with visual disabilities, especially those using screen readers, better distinguish the text for each link. A vertical bar or pipe (|), asterisk (*), or colon (:) are commonly used. You can use style sheets to hide these, if you don’t like how they look.

Make link text descriptive enough to stand on its own, even taken out of context. The text shouldn’t be longer than about ten words. Make it as concise and clear as possible. You can test them by reading aloud the links to someone else. See if the other person has a good idea to what it will link. Assistive technology [1] may allow users to read only the links on a page. If the links are descriptive, they will help users find what they want faster.

Provide a way for disabled users to skip a list of repetitive links. These are usually called “Skip navigation” links because they typically apply to global navigation. There are different ways to handle them. The easiest way is to use a text link, which all users can view. Put the link at the top of the list of links and link it to a named anchor tag at the bottom of the list. If you don’t like how the text looks, you can hide it somewhat by making the font color the same as the background color. If text takes up too much room, you can recycle a classic Web designer’s trick. Dig up the 1 by 1 pixel graphic that we all used for layout. Use the image for both the link and the anchor. It takes up very little space and sighted users shouldn’t notice it. The image can be the background color or transparent.

However, you should avoid transparent images since some versions of Netscape 6 treat fully transparent images like they are missing. It displays the ALT text in its place and can look quite jarring. If you use the 1 by 1 pixel image, make the ALT text associated with it short and clear about its purpose. Label the link something like “Skip the navigation”. Label the associated anchor something like “End of navigation” or “Main content”, if the main section of the page follows it. For other lists of links you need to allow the user to skip, choose something else short, but appropriate.

It may help disabled users if you provide “Skip-to” links. You can handle these the same way as “Skip navigation” links. Use these to help users link directly from important section to important section of a page, or to link directly from the top to the main content section on the page. They can be especially useful on content rich pages.

Fonts

Percentages and em’s are two common ways to size fonts relatively. For reference sake, 1 em roughly equals 100%. I recommend percentages because of problems Internet Explorer 3.x (IE3) for Windows has with em’s. Em’s are not supported correctly. IE3 interprets em’s as pixels. So, a font size of 1.25 ems will be displayed as 1.25 pixels.

Having said that, I should also warn you that Internet Explorer 3.x (IE3) handles percentages strangely. Instead of making fonts illegibly small, it may make percentage-sized fonts incredibly large. It calculates the percentage you specify as an addition to the default size of the element. This means if IE3 assumes an <H1> is twice (200%) the size of unstyled text and you specify your <H1> as font-size: 200%, it will display the <H1> as 400%. It’ll be huge, but legible. I still recommend percentage-sizing. The size of percentage-sized fonts may vary slightly from browser to browser, but it’s a negligible price to pay for legibility.

Relatively sized fonts are a great idea in theory but may prove problematic in practice. If you use style sheets for font sizing, be careful how you structure your page. Inheritance could pose a problem if you nest elements. (This applies to more than fonts.) For example, you could end up with text that is 80% of an element that is 80% of another element that is 80% of the size you want. Even with these headaches, the user benefits of relatively sized fonts far outweigh the drawbacks.

Tables

We all know tables should only be used to display tabular data. We all know we should use style sheets for layout. At the same time, we’re caught in the Catch-22 of supporting older browsers. The compromise is to use as few tables for layout as possible. When you use them, follow some simple advice.

Size layout-only tables using percentages. Use percentages both for the total width of the table and for the width of individual table data cells, (if you choose to specify these). This makes your content fit into the user’s screen size better. Many people design for 800 by 600 pixel screen resolution, but that may cause problems for users working with a smaller screen size. Relative sizing reduces the risk that information will be cut off from their view and get overlooked. It will make the site more usable for many users, not just disabled ones.

Check that the content in layout-only tables “linearizes” correctly. A linearized table [2] is one where the content renders in the same order that it is marked up. A screen reader or speech browser will read each cell, one after the other. Using column based text layout may pose a problem. Depending on how you handle the layout, the user may get information out of its correct order. Nested tables further complicate how tables linearize, but even a poorly marked up simple table may cause confusion for users who cannot see your layout.

If you use nested tables, check how content will render when linearized. If assistive technology is unavailable for testing, try something as simple as the Lynx browser. Although it may not render everything exactly as screen readers do, it’ll give you a general idea of how it may appear. To check individual pages without downloading the application, try Lynx Viewer. It doesn’t use the most recent version of Lynx, but it works well for quick checks of existing Web pages.

Tables are commonly used to lay out forms. If you use them, double-check the tab order and how the entire form linearizes. Place form elements immediately after the text associated with it. This way, users won’t have to backtrack. They will know what they need to enter into the field before they are requested to enter it.

Data tables are more complex and require more markup to make them both accessible and usable. However, there are some basic things designers can do. In the table tag, use the summary attribute to provide a short description of the information the table contains. You may also add the caption attribute to provide a kind of title for the table. This will help disabled users decide if they can skip the table. Indicate table header by using the appropriate <TH> tag. Don’t just use a normal table data cell and make the text bold. Your goal is to markup the table in a way that conveys the most information possible.

Color

Don’t rely on color alone to provide information. Visually impaired users will be out of luck, and colorblind users may not fare much better. You may use page context and description, in addition to color, to convey information.

Color-based navigation is a common mistake. Some designers will change the color of links and remove the underline. Unless context makes it clear, green links may be meaningless to red-green colorblind users. The underline serves as an essential visual cue to indicate that green text is a link.

If you must use color to convey meaning, keep a few things in mind. Color contrast is critical for colorblind users. For example, red-green colorblind users can see red and green, but can’t distinguish the two. However, colorblind users can usually distinguish between very dark and very light colors, even of the same hue. So, it’s possible to use red and green as long as the brightness highly contrasts and they aren’t used together. If you must use different colors of the same brightness, use a combination of blue, yellow, white or black. These are the most easily differentiated [3]. Don’t use color only to mark special sections of an image, such as a pie-chart or navigation bar. It’s more effective to combine color with a texture, shape, or other visual effect. Of course, provide text labels to convey your color-based meaning to blind users.

Test both live sites and those being developed. The simplest test is to print a Web page in black and white. (This isn’t perfect because it converts all colors to black or white, which isn’t necessarily the same effect as how a colorblind person will see it.) While you create graphics, do quick checks by converting them to grayscale. When you select the color scheme for a site, check how those colors may appear to colorblind users. There are various resources on the Web to help you do this. BT’s Color Transformations chart shows how Web safe (hexadecimal value) colors look to users with different forms of colorblindness. It even links to a chart with the RGB decimal color equivalents and other charts that break down the 216 color Web-safe palette into colors that are seen as yellows, blues or greys (neutral). Vischeck is another good resource to help you check how your site may look to users with common forms of colorblindness. It has various plug-ins and a free, Web-based check for deuteranope, red-green color blindness, which is the most common form.

Device independence

Allow users to access page elements using a mouse, keyboard, voice input, or other input devices. These elements may include: navigation, links, forms, frames, scripts, and other functionality.

Keyboard access is the most commonly overlooked device. Go through the site with a keyboard only. Make sure users can logically tab through links and activate form elements. Radio buttons and check boxes may be the most problematic. If you must use JavaScript functionality, use logical event handlers instead of device-dependent ones.

Other Pitfalls

Use the clearest and simplest language appropriate for a site’s content. Make your points concisely. Logically break content into small chunks and keep pages short. Keep your text left-justified to make pages easier to scan. This will help all users, but especially those with cognitive disabilities, such as dyslexia or learning difficulties. This may be the largest part of your disabled audience. A simple test is to have a friend’s kid take a look at the site. If the average 10 to 12 year old “doesn’t get” the site, you may need to rework things. You want to make things easier for all users.

Use style sheets for presentation, when possible. If you use them, make sure the site is still usable when they are turned off. Check that everything displays in the correct order and is legible.

Use header tags, such as <H1> and <H2>, correctly to indicate the document structure. Use them in numbered order on a page. Don’t use a <H4> tag to markup the first header just because you prefer how the font looks. If you don’t like how it looks, you can always resize it using style sheets.

Avoid using frames. If you must use them, make sure you label them with descriptive title and name attributes. (Some assistive technology will read one instead of the other to the user.) If the user knows what content the frame contains, they can better navigate through them.

Avoid using browser-specific tags. They may not render correctly on other browsers. It’s best to use W3C standards-compliant markup. If we all adhere to standards and play by the same rules, it’s harder to leave people out.

If your site requires a plug-in, provide a link to download an accessible version of the plug-in.

Avoid using links that create a new browser window. If you do use them, warn users.  Users may not be aware of the shift in their system’s focus.  It may disorient or confuse them.  This is also a usability issue since users can’t use the Back button to navigate back and revisit pages.  It’s easy to accidentally close the wrong window and lose what you want to access.  Add a text warning message or place a small icon (with a warning in the ALT attribute) before links that will spawn a new window.

Avoid “pop-up” windows, when possible.  This has problems similar to creating a new window, but also has JavaScript complications.  Access to the “pop-up” should be device independent.  More importantly, make the content in the “pop-up” accessible if JavaScript is turned off.

When possible, avoid creating pages that periodically auto-refresh. You can’t predict the speed at which a user will access the information. If the page refreshes too quickly, a user may never be able to get to the information they need. If you must create an auto-refreshing page, warn the user and allow them to request more time, if possible.

A New Perspective

The Web is an experience. It’s more than images, sounds, text, and links. Users do things like conduct business, pay bills, and connect with other people. An accessible Web site offers the same experience to as many people possible, regardless of personal or environmental limitations. This is why I frown on separate text-only sites for the sake of accessibility. They should be a last resort. They double the work for those maintaining the site and aren’t always updated as frequently. I consider it the electronic equivalent of segregation. The text-only site is separate, but the experience isn’t necessarily equal.

There are many ways to make Web sites more accessible. Don’t be intimidated by the number or variety of things a designer can do. Build in accessibility from the earliest design phase. Even adding a few of these tips will help users. In many ways, the design of a site is as important as the markup, if not more so. With some extra attention to detail, any Web designer can produce pages that are both more accessible and usable for everyone.

Endnotes:

1. The Definition of Assistive Technology from the Tech Act
   http://tatp.edb.utexas.edu/library/atdef.html
2. Web Content Accessibility Guidelines 1.0–Linearized table
   http://www.w3.org /TR/WCAG10/wai-pageauth.html#linearized-table
3. Colour Blind Design Hints and Tips
   http://www.cimmerii.demon.co.uk /colourblind/design.html

Resources:

W3C WAI homepage
http://www.w3.org/WAI/

W3C Web Accessibility Initiative Checklist for Web Content Accessibility Guidelines 1.0
http://www.w3.org /TR/WAI-WEBCONTENT/full-checklist.html

Section 508 Official Web site
http://www.section508.gov/

Section 508 Standards § 1194.22 (Web guidelines)
http://www.section508.gov /index.cfm?FuseAction=Content&ID=12#Web

Web Design for Dyslexic Users
http://www.dyslexia.com/qaweb.htm

Vischeck
http://www.vischeck.com/index.php

A-Prompt accessibility verification software
http://aprompt.snow.utoronto.ca/

Lynx browser
http://lynx.isc.org/

Lynx Viewer
http://www.delorie.com /web/lynxview.html

Designing More Usable Web Sites
http://www.trace.wisc.edu/world/web/

WebABLE: Tools and Utilities
http://webable.com/library/linkspage.html

Related Topics: Accessibility, Web Design