Basic Web Accessibility Tutorial: Design and Development
Version 1.0, October 14, 2009
This is part 2 of a 3 part tutorial. Here is a short description of each part.
- The degree to which a device, service, or environment can be used by as many people as possible. Web accessibility means that people with disabilities can perceive, understand, navigate, interact with, and contribute to the Web.
- Web content
- Any Web page or Web application that is displayed in a Web browser. This is normally HTML content, but might also include other non-HTML elements, such as Java applets or multimedia players.
- Accessible Web content
- Web content that has been designed and created to comply with accessibility guidelines, with the goal of enabling the largest possible audience to use the content, regardless of disability or method of access.
There are many things we can and should do to make our Web pages accessible.
The Web content accessibility requirements listed here are based on Texas state law (Texas Administrative Code, Chapter 206) and Federal law (Section 508 of the Rehabilitation Act). In some cases, the Worldwide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0) are used to clarify the requirements.
The easiest rule to remember is that small and simple is easier to understand than large and complicated. It is very difficult to provide specific rules for the size and layout of a page, but keep the "smaller, simpler" rule in mind when planning the design of each page in your Web content.
The following sections describe design and coding considerations for making your Web content easier to view/access and understand, as well as tools and techniques for testing the accessibility of your pages.
When designing your page, be sure there is sufficient contrast between the text and the background.
- Use dark text on a light background or light text on a dark background, and do not use an image or other pattern as the background for text.
- Use a contrast analyzer to verify the contrast between text and background is sufficient.
- Example: See the
Web Accessibility Toolbar for IE from The Paciello Group. The "Contrast Analyser" application is found in the Colour pulldown on the toolbar. By selecting the text and background colors from your Web content, the analyzer will judge whether the contrast is sufficient based on the algorithm suggested in the W3C WCAG 2.0 specification.
- Break blocks of text into logical paragraphs, with white space (blank lines) between the paragraphs.
- Use paragraph tags (
<p>) when appropriate to separate text into readable pieces. The Web browser automatically adds space between paragraphs, unless the paragraph style has been modified.
- Smaller sections of text can be more easily read and understood by people with certain cognitive issues.
- If you specify fonts, use standard, simple fonts such as Verdana or Arial instead of fancy or decorative fonts. Decorative fonts are often much harder to read than simple fonts.
- Example: Use a CSS attribute such as "font-family: arial".
- Simple, clean text style may help people with cognitive issues as well as people with limited vision to read your content.
- Use relative font sizes instead of specific size units. This lets me use browser features to increase the font size if I cannot see the text easily.
- Use CSS attributes such as "font-size: 2.5em", "font-size: 90%", and "font-size: larger".
- Do not use "point" sizes, such as "font-size: 12pt". By specifying a exact point size, you prevent the browser from enlarging the text at the user's request.
- The ability to increase the text size will help people with limited vision read your content.
- Always provide at least one heading on the page, at the beginning of the main page content. The first heading on a page should normally be an
- Use additional heading tags to separate other sections of the page, as needed.
- Provide headings to organize or group your content whenever logical to use them.
- Headings will help people with cognitive issues, people who use screen readers, and people who have limited vision to more rapidly scan and understand your content.
- General rule: If it looks like a heading, it should be marked up as a heading.
- Do not make text look like a heading by making it bold and increasing the font size. Again, if it looks like a heading, it should be marked up as a heading (using the appropriate HTML element, such as
- If an
<img> tag is used, it must include an 'alt' attribute. This attribute lets you assign alternative text (also known as "alt text") that describes the image.
The text provided in the alt attribute is what the screen reader will announce when it encounters the image. If an image is purely decorative or redundant, set the alt attribute to null (
note that the null value is indicated by two quotation marks with no space
between) to alert the screen reader to ignore the image.
- If you use CSS to display a background image, there is no option to add alt text, so a screen reader will ignore the image. For this reason, you may use CSS only for purely decorative or redundant images, and not for images that convey information.
- Hints for creating alt text.
- Describe the image in as few words as possible. Keep it short and concise.
- Use null alt text only for images that are truly decorative or provide completely redundant information. If you added a picture to the page for sighted users, then a person who is blind will probably be interested to know that it exists and what it is.
- Do not start with the word "Image" or "Picture". The screen reader will announce the fact that this is an image.
- If an image contains text that you expect people to read, include that text in the alt text exactly as it is written in the image.
- If the image is a logo, start with the word Logo.
- If the image contains a lot of information (like a graph or chart), do not try to include all of the information in the alt text. Instead, add the text description to the page text either before or after the image, or create a separate page just to describe the image. Then, use the alt text to tell the user where to find the full description.
- If an image is used as a hyperlink, see the "Image links and image maps" section for more hints.
- For decorative images, the image tag looks something like this:
<img src="glyph.gif" alt="" … />
- For a picture of kittens playing:
<img src="kittens.gif" alt="Kittens playing with ball of yarn." … />
- For a DARS logo:
<img … alt="Logo, Texas Department of Assistive and Rehabilitative Services, DARS" … />
- For a complex bar graph, include the type of graph, the title, and instructions on where to find a full text alternative:
<img … alt="Bar graph, Monthly revenue, Full text description follows." … />
Be very careful when adding elements, either text or images, that flash, blink, or contain repetitive movements. These elements can cause a severe distraction, and can in some cases cause seizures. It is best to avoid using these elements, if possible.
If you decide you must include elements that blink, flash, or that provide repetitive movement, use the following guidelines:
- For flashing or blinking elements, verify that the flash or blink rate of the element is no faster than 2 to 3 times per second.
- For elements that contain repetitive motion, verify that motion does not repeat at a rate faster than 2 to 3 times per second.
If you have trouble counting the number of blinks in one second, you can try these steps.
- Count the number of flashes, blinks, or movements that occur in 10 seconds.
- Divide that number by 10 to determine the flash rate.
- If the result is greater than 3, you must either reduce the rate of flashing, or remove the element from the page.
- If you can see that an element is flashing or blinking but it is too fast to count, then the element fails this test and you must either reduce the flash rate or remove the element from the page.
A text equivalent is needed for both audio and video.
- For recorded audio-only content (like a recorded radio broadcast, or a podcast lecture):
- Provide a text transcript of the content. The content should include both spoken dialog and a description of important background sounds.
- This will help people who are deaf or hard of hearing.
- For recorded video-only content (like a recorded section of a security video that contains no audio):
- Provide a text description of the important visual action seen on the video, with a time index for each incident, as appropriate.
- This will help people who are blind or visually impaired.
- For recorded audio+video content (like a recorded TV program, movie, or home-made video):
- Provide captions for the video that include spoken dialog and descriptions of any important sound effects, and that are synchronized with the action and dialog in the video. This will help people who are deaf or hard of hearing.
- Provide a text transcript of the video that includes not only the spoken dialog and descriptions of important sound effects, but also includes a description of the important visual action, much like a screenplay. This will help people who are blind, people who have limited vision, or those who are both deaf and blind.
- You can also provide an alternative soundtrack that contains an audio description of the action in the video interspersed with the spoken dialog from the main soundtrack.
- For all audio and video content:
- Do not automatically start the playback of audio or video when the Web page is loaded, unless there is a compelling reason.
- Be sure there is a method of stopping the playback of audio and video content. The audio may interfere with the ability to hear a screen reader.
- Do not use color as the only method of conveying information. If you use color to convey information, be sure to use a text-based cue to convey the same information.
- Example: Instead of saying "The required fields are shown in red," mark required fields with an asterisk in addition to coloring the field red, and say "The required fields are marked with an asterisk and shown in red."
- Similarly, do not use text decorations as the only method of conveying information. For example, instead of saying "The winners are shown in
bold," you might say "The winners are marked with a star and listed in bold."
Cascading style sheets (CSS) can be used to manage much of the look and feel of a site. CSS contains instructions determining font styles, colors, and page layout, or placement of content on the page. The use of style sheets is strongly encouraged.
However, there are people who may be using browsers that do not fully support style sheets, and other people may override your style sheets with their own. The most common reason for overriding style sheets is to set a preferred high contrast or large font scheme. To ensure that those people can use your Web content, you must verify that your Web content can be successfully viewed and used even when your style sheets are disabled by the browser.
- This means you must disable style-sheet support in the browser and manually verify the content can be viewed and understood with no style sheets active.
- If CSS is used to add content to a page, including background images, you must verify that no meaning is lost on the page when CSS support is disabled.
- Here is how to disable style sheets in your browser:
- In Internet Explorer, use the Web Accessibility Toolbar or a similar tool.
- In Firefox, select "No Style" in the Page Style submenu, found under the View menu bar option.
A data table is a grid that contains a set of related information in row and column format. A data table contains column and/or row headers.
Visually, data tables are easy to understand because a sighted user can scan up to the top of the column or to the beginning of the row to read the column and row headers for any data cell in the table. For those users who cannot see, it is not so simple. If I use a screen reader to navigate from one data cell to another, I depend on the screen reader to announce the column headers as I change columns, or to announce the row headers as I change rows.
You, as the page author, must include table header tags (
<th>) to identify the row and column headings in your table. A complete description of markup for accessible tables is beyond the scope of this tutorial, but here are some basic tips.
scope attribute to tell the screen reader whether this is a row or column header. For example:
- For column headers, use
- For row headers, use
For more complex tables, multiple column headers or multiple row headers might apply to a single data cell. In this case, you will need to use id and headers attributes to fully inform the screen reader which headings apply to each data cell. However, keep in mind that people who use screen readers and people who have cognitive issues will find it more difficult to understand a complex table. If you break a complex table into two or more simpler tables, it will often help everyone.
More notes on tables:
- Don't be tempted to say the rules don't apply to your table because you are not using table header tags. If I must know the contents of one cell in the table to understand the contents of another cell, then it is a data table, and should be coded as such.
- Sometimes it is better to use a list than a table. If you are using a table to format a list of items, consider coding it as a list and using CSS for formatting.
The following sections describe design, coding, and test considerations for making your Web content easier to navigate using the keyboard and with a screen reader.
If the main page content is not the first thing a user encounters at the top of the page, or if there are blocks of repeated information on multiple pages, provide "skip links" to allow keyboard users to jump directly to the main page content. For example, many pages display a banner across the top of the page that contains a logo, links, or maybe a search field. There is often a section of site navigation links along the left side of the page. Provide links to skip past these sections, to enable keyboard or screen reader users to move to the more important content on your page.
Here are some guidelines for skip links.
- At the top of the page, provide a link to skip directly to the main content.
- If there are common blocks of information on multiple pages, provide links to jump around those too.
- Make sure the link is visible when it has focus. When it does not have focus, it can be hidden for visual design reasons, if you wish, but it must be visible for sighted keyboard users when they tab to the link.
- These techniques help screen reader users and sighted keyboard users.
Use meaningful link text for all hyperlinks.
Image links and image maps are a combination of images and links.
- An image link is an image that links to a single target page.
- An image map is an image that links to multiple targets. For example, if a page contains a picture of a United States map, clicking on each state might link to that state's Web site.
Because images and links are both used, the accessibility rules for both images and links apply. See the
Images section for general rules on alt text for images.
- All images that are links must have non-null alt text. (See exception below for
- The alt text must describe the target of the link.
- If the picture itself is significant or of interest, the alt text should include a description of the image in addition to describing the target of the link.
- If the DARS logo at the top of a page links back to the DARS home page, the alt text should reflect both pieces of information, so might look like this:
alt="Logo, Texas Department of Assistive and Rehabilitative Services, Link to DARS home page."
Notice that the fact that the image is a logo is mentioned in addition to the target of the link, which is the DARS home page. In this case, since both the image and the link destination are described, using the word "link" in the description is acceptable. This is another case where you must use your judgment when writing the alt text.
If an image is placed next to a text link, and the image links to the same target as the text link, use null alt text for the image. When using a screen reader, I do not need to hear the link target twice; once is sufficient. Take this example:
Consider what will happen if the alt text for the image says "Section A". When announcing this section, the screen reader will say "Section A Section A", once for the image and another time when reading the text. Setting the image alt text to null will eliminate this duplicate announcement.
When coding this example, you must decide whether to make both the image and the text link to Section A, or just make the text link to section A.
- Either way, the image alt text should be set to null.
Here are two acceptable ways to code the above example.
First, here is an example of making both the image and the text to link to the destination (to be 'clickable'):
<a href="#link-to-sectiona">Section A
<img src="images/lettera.jpg" alt="" ... />
Second, here is an example of making only the text link to the destination. The image is not part of the link:
<img src="images/lettera.jpg" alt="" ... />Section A
Notice that in both examples, the image alt text is set to null, to prevent the screen reader from announcing redundant information.
Some pages use HTML frames to divide the Web page into separate scrollable areas. The contents of each frame are defined in separate Web page files. Be sure to identify the content found in each frame as follows.
<title> tag must be included in each individual frame page. The title must provide a concise description of the contents of the frame, just as the title does on a page that is not using frames. A screen reader will announce the contents of the title tag for each frame.
- You can also provide a title attribute within each
<frame> tag defined in the main page. If the title attribute is used, a screen reader will most likely announce the title attribute rather than the title tag found in the included frame page.
- You should consider the use of the title tag in the included file to be mandatory, and the title attribute in the frame tag to be optional. (Unfortunately, some confusion might result from the use of the word "title" in both the title tag and the title attribute. Remember, the title
attribute is part of the frame tag found in the main page, and the title tag is found in the HTML file that defines the content of a specific frame.)
- Suppose a page contains three frames, one across the top of the page that contains the page banner, one down the left side of the page, containing navigation links, and the main content frame filling the remaining area below the banner and to the right of the navigation. Those three frames might have titles something like these:
- For the banner: "My web page, banner." (This may be more specific, depending on the contents of the banner.)
- For the navigation: "My web page, navigation links."
- For the main content: "My web page, main content." (Consider making this more specific to the actual content found on the page.)
- This helps people who are blind and other screen reader users. The screen reader will announce the provided title as you navigate to each frame.
- Note: It may be difficult to change these titles in some Web development environments. If you cannot customize the page titles for each frame, you must, at minimum, verify that each frame has a unique title to allow the user differentiate between frames.
The following sections describe design, coding, and test considerations for making your Web content easier to use when the content requires some sort of user interaction.
If you link to PDF documents, Word documents, or any other content that cannot be displayed directly by the Web browser, be sure to provide a link to a downloadable application that will let me view the document or other content.
- For example, if I do not have a Word file viewer on my system, I will not be able to open linked Word documents. In that case, you must provide a link to a freely downloadable viewer application for Word documents.
- Note: If you are publishing pages to the DARS internet site, the template for those pages includes a link to File Viewer Information in the page footer. That link satisfies this requirement.
Important note about linked documents
If you link files from your Web site, be sure you know who your audience is. If you are publishing files for use by employees on the internal DARSnet site, for example, you know that employees have access to Adobe Reader and to Microsoft Office applications, so publishing PDF documents, Word documents or PowerPoint presentations is okay; DARS employees have the necessary viewers or applications to open these types of documents.
However, if you are publishing files to the internet, you cannot be sure that your audience has access to Microsoft Word or the other Office applications. Even though Microsoft does provide free downloadable viewer applications for Word and other document formats, those viewers may not be completely accessible and may not be compatible with the user's operating system..
Also, be aware that PDF, Word, and other Office applications have their own set of accessibility challenges. If you link to those types of files, it is your responsibility to verify that the information in those files is accessible. If possible, the best choice is to always publish your information as Web content, using HTML. In general, that is the most accessible cross-platform option available.
If you use form elements, like radio buttons, checkboxes, or text input fields, be sure to use
<label for="…"> tags to associate text labels with each of the form elements.
- Example 1, radio button:
<input type="radio" name="dbflavor" id="flavor" value="chocolate" />
Will look like this in the browser:
- Example 2, check box:
<input type="checkbox" name="vehicle" id="v1" value="Car" />
<label for="v1">I have a car.</label>
Will look like this in the browser:
- Example 3, text input field:
<label for="fname">First name:</label>
<input type="text" name="firstname" id="fname" />
Will look like this in the browser:
- The "for" attribute in the
<label for> tag is associated with the "id" attribute of the input field. Since duplicate "id" attributes are not allowed on a page, the
<label for> tag can be associated with only one input field.
It is beyond the scope of this tutorial to describe how to make all scripted elements accessible, but here are some general rules:
- Make sure I can use the keyboard to use any scripted elements. Remember, if you can do something with the mouse, you must provide a way for me to do the same thing using the keyboard.
- Make sure a clear visual focus is provided at all times, so I know where I am as I use the keyboard to navigate or control the scripted element.
- Make sure the element displays with sufficient default contrast between text and background colors, and that color is not the only method used to convey information.
- Make sure a screen reader can announce sufficient information, such as the name, role, state, and value of the element, so that I can understand and use it even if I cannot see it.
If there is a session timeout requiring that a task be completed in a specific amount of time, use the following guidelines.
- Make it clear that a session timer is running, to avoid surprising the user with a timeout event. For example, on the login page of a Web application, you might add a note saying "For security reasons, this session will be timed out after 10 minutes of inactivity."
- Give me an option to extend the timer, unless there is a reason you cannot. If you cannot extend the timer, for example, because of a real-time event outside of your control, explain why.
If you include a Java applet, a multimedia viewer, or any other non-HTML content that requires user interaction, you must verify that the applet or content conforms to all Section 508 accessibility requirements for software applications.
The details of this requirement are beyond the scope of this tutorial, but here are some basic things you must verify:
- Make sure I can use the keyboard to accomplish any tasks that can be done with the mouse, and that clear visual focus is always evident.
- Make sure a screen reader can announce appropriate information for all controls as you navigate the application using the keyboard.
- Make sure color is not the only method used to convey information, and that the default contrast is sufficient.
- If the content does not comply with these requirements, make sure that an accessible alternative is provided.
This tutorial covered design and development issues related to Web accessibility issues. For coding examples of many of these concepts, proceed to the next portion of this tutorial:
Basic Web Accessibility Tutorial: Examples.