Tutorial FrontPage 2003

www.webaim.
org
Using FrontPage 2003 to Create Accessible

Web Content
Author: Jon Whiting
Date: November 2004
Contents
Introduction
New Accessibility Features in FrontPage 2003
CSS support
Improved XHTML support
Accessibility evaluator
Creating Accessible Content
Change the default template to one that is valid
Adding alt attributes to images
Creating accessible client-side image maps
Defining table headers
Adding labels to form elements
Giving titles to frames
Adding headings and subheadings
Introduction
FrontPage is one of the most popular HTML editors on the market. There are several reasons for this:
The price is relatively low when compared to Dreamweaver or many other editors.
Its MS Office interface will be familiar to many people.
It has a powerful Spell Checker and other proofing tools.
It integrates with Office products like Word.
Just like every tool, FrontPage does have its weaknesses:
The default template you use when starting a new Web page is not compliant with HTML standards
(more on this below).
Changing an element's properties can sometimes take several steps.
Some basic accessibility features must still be added manually (more on this below).
Despite some of these shortcomings, it is definitely possible to create accessible Web pages in
FrontPage, often without leaving the WYSIWYG environment.
1 de 9
Note: Though many of the accessibility features are the same, this article focuses on
FrontPage 2003 and not on previous versions. Read the archived tutorial, Using FrontPage
2000 to Create Accessible Content .
New Accessibility Features in FrontPage 2003

CSS support
CSS (Cascading Style Sheet) support has been greatly improved in FrontPage 2003. Not only can
you use layers for CSS layout, but you can also create CSS-based templates and themes. You can also
preview your CSS-based layout in the design view.
Improved XHTML support
Frontpage offers improved, but incomplete, support for XHTML. While there are are no features to
actually create XHTML pages in the WYSIWYG view, FrontPage incorporates XHTML elements, like
lowercase tags and the use of CSS for layout. You can also create XHTML documents in code view as
well as edit XHTML documents created in another program.
Accessibility evaluator
FrontPage includes an accessibility evaluator. To use it, click on Tools > Accessibility (F8). A dialog
box will appear with several options:
Check where: You can choose to check all pages in the site, all open pages, selected open pages, or
the page you are currently working on.
Check for: You can choose to evaluate your page(s) according to WCAG Priority 1 guidelines,
WCAG Priority 2 guidelines, Section 508 standards, or all of them.
Show:
Errors—Definite accessibility problems, similar to the issues marked in red in The Wave.
Warnings—Possible accessibility problems, similar to the issues marked in yellow in The
Wave.
Manual Checklist—This is a list of potential accessibility problems that this checker cannot
detect, but should be checked by the developer.
2 de 9
Once you have chosen your preferences, select the Check button. FrontPage will generate a report
that lists the page name, line number, checkpoint and summary. From here, you can either review the
issues in the report window or you can generate an HTML version of the report by selecting the Generate
HTML Report button. The HTML Report feature creates a more visually-pleasing, checklist-style report
that you can save and review later.
Creating Accessible Content

Many of the following accessibility techniques are possible in the WYSIWYG environment, but
sometimes it is necessary to make the changes to the HTML code itself. Before FrontPage 2000, you
would sometimes make a change to the code, only to have FrontPage change it back. This isn't really a
problem anymore, but if you are using a pre-2000 version of FrontPage, upgrading will provide you with
many additional accessibility features.
Unless it is indicated that a feature is new to FrontPage 2003, all of the following
techniques are possible in FrontPage 2000 through 2003.
Change the default template to one that is valid
One of the strengths of FrontPage is its ability to create templates. When you create an accessible
template, you can reuse the same template for your whole site (or at least for the appropriate parts of your
site). By reusing templates, you only have to worry about the parts of your site that are not included in the
generic template.
Many Web developers use scripting languages such as Java Server Pages, PHP, Perl, Cold Fusion
and others to create templates. These languages allow for great flexibility and programmability—much
more than FrontPage's template and theme features. Still, the concept is the same: use templates, and make
them accessible.
3 de 9
The default blank page that displays when you start FrontPage 2003 does not have any direct
accessibility issues, but it is not standards-compliant, valid HTML. There are 3 things you can do to
change this.
Add a DOCTYPE declaration using shortcuts
Microsoft suggests that you can create a valid template by adding a DOCTYPE declaration using
built-in code snippets. The DOCTYPE declaration tells the browser what version of HTML (3.0, 4.01,
XHTML 1.1, etc.) to use. This is a necessary element in any accessible Web page template, but there's
more to a standards-compliant template than a DOCTYPE. Even though this technique offers an
incomplete accessibility solution, it is a step in the right direction.
To insert a code snippet, make sure you are in code view. Position the cursor where you want to
insert the new code (in this case, it will be at the very beginning, before the <html> tag. Press Control +
Enter and a dropdown list will appear.
Choose the snippet you want to insert, dt4 for example, and that bit of code will be inserted.
Change the default template
The default Web page template (normal.htm) is normally located in the templates directory of
Microsoft Office. On most computers, the document is located in the C:\Program Files\Microsoft
Office\Templates\1033\Pages\normal.tem directory. The file you need to change is named normal.htm.
Open this document in a text editor of some sort (Notepad, Wordpad, BBEdit, or something similar). Then
change the template to something that is (X)HTML compliant:
The template will vary based on the (X)HTML syntax version you choose—HTML 4.0 Strict,
HTML 4.01 Transitional, XHTML 1.0 strict or XHTML 1.0 transitional, etc. There is a syntax for every
HTML and XHTML specification. Just make sure the template you choose is standards-compliant by
running it through the W3C HTML validator .
The normal.htm template is only used when you create a blank page that has not been assigned a
template or theme. If you are using either of these FrontPage features, you will need to edit the template
pages for those items. These template files should be located in the same directory as the normal.htm
template described above.
Create multiple templates
This technique is a combination of the two previous techniques. If you know that you will be using
more than one version of HTML, then you can create multiple templates, one for each HTML version you
plan to use. There are two methods for doing this:
First, create a Web page template in FrontPage or in a simple text editor for each version of
(X)HTML you want to use. Then, when you want to create a new page, simply open the appropriate
template instead of creating a new page.
The second option is the same as the first, except you save each of the new templates as a code
snippet instead of an HTML file. To create a new code snippet, go to Tools > Page Options (Alt+T, A),
then select the Code Snippets tab and then the Add button. A box will open with 3 fields:
Keyword: This should be a one word description of the snippet.

Description: You can add a longer description of the if you choose to.
Text: This is where you enter the new template code, or whatever piece of code you frequently use.
4 de 9 31/01/2005 10:57 p.m.

You can then add them to your code in the same way mentioned previously (Control + Enter in
Code view).
Note: Even if you plan on using this method, you should probably still change the
default template to the syntax you use most often. That way you can be sure your page, at
the very minimum, will be compliant with the specified version of HTML
Adding alt attributes to images
Adding alt attributes to images is easy in FrontPage. Right click on the image and select Picture
Properties, or with the image selected, press Alt + Enter. Then enter the alternative text in the Text field
under Alternative representations. If you would like to add empty alt text for spacer images and other
unimportant graphics, check the box next to the Text field but leave the field blank. You can only add
empty alt text in Frontpage 2003.
FrontPage 2003 (but not earlier versions) supports the longdesc attribute. If an image is too
complex to describe with simple alt text, you can link to a page that provides a long description by
entering the URL in the Long Description field. You will have to create a simple HTML page with the
the long description yourself.
Creating accessible client-side image maps
To create an accessible client-side image map, follow these steps:
Insert the image into your Web page.

Make sure the Pictures toolbar is visible (View > Toolbars > Pictures)
Use the Rectangle, Circle, or Polygon Hotspot tool to create hotspots on the image where you want
links.
The Create Hyperlink window will open after each hotspot is created. Select the button labeled
ScreenTip. A dialog box will appear with where you can enter the alt text. Although this prompts
you for ScreenTip text, it really enters the alt attribute.
5 de 9
Note: If you have Frontpage 2000 or earlier, you will have to enter alt text for
hotspots in the code view.
You can add alt text to an existing hotspot by double-clicking the hotspot and following the steps
above. Remember that hotspots should NEVER have empty alt attributes—let the user know what the
hotspot displays and where the link will take them. The main image MUST also have an alt attribute,
but it can be empty (alt="") if it does not convey any new information.
Defining table headers
To define a table header for data tables in FrontPage, select the cell you want to make a header.
Right click on the cell, then select Cell Properties or select Table > Properties > Cell. When the Cell
Properties dialog box appears, select the Header cell check box.
If the table is just used for layout (not a true data table), then there is no need to specify table
6 de 9
headers.
Adding labels to form elements
Create your form using the Insert > Form menu.

Each form element (text box, radio button, checkbox, or drop-down menu) should have descriptive
text that informs the user what to enter or select. Put the label adjacent to the form element (though
it technically can go anywhere in the page).
Click and drag and select the form element AND its descriptive label. Go to Insert > Form >
Label. FrontPage has now associated the text label with the form element. Repeat for all of your
form elements.
Sometimes FrontPage's LABEL option is not enough - labels often are not adjacent to the form
elements (if you use tables for layout). Changes to labels that are not adjacent to their form elements
must be done in HTML view
Giving titles to frames
A frameset is a Web page which defines a collection of at least two other separate Web pages, which
are combined in the same visual space. Visual users usually experience framesets as a cohesive entity.
They can scan the contents of multiple pages all at once.
Those using screen readers cannot quickly scan the contents of multiple pages. All the content is
experienced in a linear fashion, one frame at a time. Frames are not inaccessible to modern screen readers,
but they can be disorienting. One of the most important things you can do to increase the accessibility of
frames is to give each frame a title.
Note: This feature is new to FrontPage 2003.
There are two different ways to add titles to your frames.
1. You are prompted to add a title when you save each frame.
2. Right Click on the Frame and choose Frame Properties. A dialog box will appear with several
fields. Type the descriptive title into the field labeled Title.
7 de 9 31/01/2005 10:57 p.m.

Adding headings and subheadings
Remember to use actual headings (h1-h6) to structure content, and not text formatting, such as font
size or bold to give the visual appearance of headings. Assistive technologies and other browsers rely
upon the literal markup of the page to determine structure. Items that are bolded or display in a bigger font
are not interpreted to be structural elements.
When the cursor is in a line of text, you can select what type of text it should be, whether a
paragraph, heading 1, heading 2, etc. This can be done from a dropdown list at the far left side of the of
the Formatting toolbar.
See also:
Related WebAIM resources:
Using FrontPage 2000 to Create Accessible Content

Tutorial: Creating Accessible Images
Tutorial: Creating Accessible Tables
Tutorial: Creating Accessible Forms
8 de 9
Tutorial: Creating Accessible Frames
Tutorial: Semantic Structure
Related external sites:
Building Accessible Web Sites with FrontPage 2003

W3C Markup Validation Service
Copyright (c) 1998-2005 WebAIM (www.webaim.org). All rights reserved.

Terms of Use: This document may be reproduced and distributed in print or electronic format only if it is offered at no cost to
recipients and as long as full credit is given to WebAIM, including a link to the WebAIM Web site, and as long as this Terms of Use
notice remains intact.
9 de 9
www.webaim.org
Creating Accessible Images

Part 2: Color & Contrast
Part 2 Contents
Color
Contrast
2.1 Color
The accessibility rule is to ensure that you do not use color alone to convey meaning. This phrase is
a bit nebulous to some people. What does it mean to convey meaning with color alone? You may
remember the map of the London Underground from our discussion about color-blindness in the previous
unit. Let's take a look at it again:
A person who can see colors will have no trouble distinguishing between the red line, the dark blue
line, the light blue line, and so on. A person who cannot see color well, due to color-blindness or low
vision, will probably not be able to distinguish the different routes as easily. Someone who is blind will
not be able to see them at all. Let's take the colors away from this image:
1 de 3 31/01/2005 10:58 p.m.

Part 2: Creating accessible images file:///d:/Microsoft/2.htm
How would you know which line to take to get to Waterloo? Before we go too far, you should know
that individuals who are color-blind can see colors (with the exception of a few rare cases), so the above
grayscale drawing is not representative of color-blindness. It is merely an example of an image in which
color is being used to convey meaning. When the colors are removed, the different routes are almost
impossible to distinguish.
Let's take a look at an example of how to circumvent this potential problem. The WebAIM Training
CD site uses colored tabs to denote the categories of links in the top navigation.
If a lighter color had been chosen for the background of the resources tabs, the text would be
difficult to read.
The method that we used on the WebAIM Training site to avoid confusion was to put a bracket over
the categories, and give the bracket a title. The brackets organize the tabs according to workshops and
resources. Even when there is no color at all on this page, the meaning of the colors is still accessible.
2 de 3 31/01/2005 10:58 p.m.

Test your Web pages to ensure that none of the meaning is lost when you remove the colors. You can do
this by printing out the page on a black and white printer, making sure that your printing preferences are
set to print background colors. You can also do as we did on this page, by taking a screenshot of the page
and then removing all color within a graphics program such as Corel PhotoPaint or Adobe PhotoShop.
To do this in windows, open up the page that you wish to check, then hit the print screen button (often
labeled as "prnt scrn"). Then open a new file in your graphics program and use the paste command
(CTRL + V). Finally, change the image into a grayscale image.
2.2 Contrast
Take another look at the black and white version of this training site above. Aside from the fact that
this is just a screen shot of the page in which the text is considerably smaller and a bit blurrier than on the
actual page, you'll notice that all of the text is easily distinguishable from the background colors around
it. Where there is a light background, there is dark text. Where there is a dark background, there is light
text. People with low vision will not have difficulty distinguishing between the different contrast levels
of the text and backgrounds.
If I had chosen a lighter color for the background of the resources tabs, the text would be difficult to
read.
Just be careful when you choose background colors that they will not decrease the contrast level to
the point of making text unreadable.

recipients and as long as full credit is given to WebAIM, including a link to the WebAIM Web site, and as long as this Terms of
Use notice remains intact.
3 de 3 31/01/2005 10:58 p.m.

www.webaim.org

Part 3: Text Within Graphics
3.1 Pixilation of Enlarged Images
Often graphics contain text as part of the image. For example, the graphic below contains the word
"University". Some users with low vision use programs that enlarge the elements on their screen so that
they can more easily see them. Unfortunately, when the text in an image is enlarged it often becomes
pixilated and difficult to read. Let's look at an example.
The graphic was enlarged to 500% its normal size. You can see that the text is difficult to read. If
real text had been used, it would have been much easier to read, as in the example below:
University
So does this mean you shouldn't use text in your graphics? In a perfect world maybe, but the current
technology makes it difficult to achieve certain designs without using text in graphics. The practical
answer is that you should try to limit the amount of text in graphics. One of the places where text inside
of graphics can be justified is in logos and trademarked images. The Internet does not offer a way to
convey the unique text of this type of image without employing a plug-in such as Flash or SVG. Still, if
there is a way to use real text, you should do so. If you must use graphical text, here are some guidelines
to follow:
make your font sizes as large as possible

use simple block fonts when possible
use good color contrast between the text and background.
A good tool for checking color contrast (as well as color-blindness compatibility) can be found at
www.vischeck.com.
Pixilated text can be especially difficult to read when there are other visual elements in the
background, as in this enlarged image of a book cover.
1 de 2 31/01/2005 10:58 p.m.

Although the white text contrasts quite well with the dark blue background, the designs of the
background obscure the text somewhat, despite the fact that these designs are subtle.

2 de 2 31/01/2005 10:58 p.m.

www.webaim.org

Part 4: Graphics That Can Cause Seizures
Part 4 Contents
Flicker and Strobe
How Can You Know if Your Graphics Will Cause a Seizure?
4.1 Flicker and Strobe

There isn't a whole lot to say about this topic, but it is all important. The main point if this:
Visual effects that flicker or produce a strobe-like effect may cause seizures in some
individuals.
Seizures induced by flickering or strobe-like effects are known as photoepileptic seizures. Seizures
can be dangerous. Don't be responsible for causing them.
4.2 How Can You Know If Your Graphics Will Cause a

Seizure?
There is no absolute threshold at which a harmless animation turns into a dangerous,
seizure-causing graphic. However, the guidelines that are used in the United States under Section 508
have set the threshold between 2 and 55 flickers per second. This does not mean that anything that moves
at that rate will cause a seizure, because that would make all videos and animations unusable. Movement
is not the issue. Flickering and strobing effects are the issue. You may not want to follow this link if you
are susceptible to seizures, but here is an extreme example of a flickering image.
Most designers don't create graphics that even approach the point that they might cause seizures, but
some multimedia developers do venture into this territory. Flash designers are especially notorious for
creating modernistic animations that flicker and strobe across the screen. Be careful when you design
your animations. Don't cause a seizure.

1 de 1 31/01/2005 10:58 p.m.

www.webaim.org

Part 5: Effective Alt Text
Part 5 Contents
Overview
The Importance of Alt Text
Adding Alt Text
How Images Are Used
Communicating the Purpose of The Graphic
Images that contain important content
Accuracy and brevity
Null alt text
Decorative images
Transparent and spacer images
Redundant images
Image Maps
Client-side image maps
Server-side image maps
Background Images
5.1 Overview
Now we get to the part that most people are at least somewhat familiar with: alt text. By the way,
there is no such thing as an alt tag, though people often refer to alt text by this name. To be technically
correct, it is the alt attribute of the <img> (image) tag. It's name is not important as its function, though,
so let's take a look at what it means to have effective alt text.
Guidelines for alt text:
1. Ensure that the text alternatives communicate the purpose of the graphic accurately
and succinctly.
2. Provide empty or null alt text for graphics which do not convey content.
3. Provide alt text for both the main image and the hot spots of image maps.
4. Do not repeat the alt text of an image in the adjacent text.
5. Do not put important images in the background.
5.2 The Importance of Alternative Text
1 de 8 31/01/2005 10:58 p.m.

One of the biggest accessibility problems on the Web today is the lack of alternative text for
graphics and images. Individuals who are blind often use screen readers or refreshable Braille devices
that read the text on the page to them. When these assistive technologies come across images without alt
text, they are unable to communicate their meaning.
When a screen reader comes across an image with no alt attribute, there are a couple of things that
could happen:
1. It could simply skip the image as if it were not even on the page.
2. It could find some text that is associated with the image such as the file name and read that instead.
The exact behavior of the screen reader varies between brands of screen readers and the
circumstances of the Web page itself, but either way, the end result is undesirable. The user either misses
the image content completely or gets some text that is probably meaningless.
Experience it for yourself
Let's listen to a recording of the a screen reader (IBM Home Page Reader 3.0 in this case) when it
comes across an image with no alt text.
Note: For the sake of illustration, the "Announce Images with no Alt text" option is activated in
Home Page Reader in this example. The default setting of Home Page Reader is to skip over images that
do not have alt text, unless they are links, in which case it reads the link destination.
Select a format: Wav | Mp3 | RealMedia | Transcript
Someone using a screen reader would have a difficult time knowing what the image was for. We
need to add a text alternative to the image. To do this we simply put alt="University of the Antarctic
logo" in the image tag. The HTML source would then look like this:
<img src="map_antarctica.jpg" width="150" height="117" alt="University of the Antarctic logo"
/>
Let's listen to Home Page Reader 3.0 reading the image--this time with alt text--so we can see the
difference.
Select a format: Wav | Mp3 | RealMedia | Transcript
Here is the image that we were listening to:
The addition of alternative text allows screen reader users to get the same information as others who
can see the image.
5.3 Adding Alt Text

Let's look at another example image:
2 de 8 31/01/2005 10:58 p.m.

The HTML code for this image is as follows:

<img src="silvia1-8-web2.jpg" alt="Portrait of Silvia Alvarez" width="311" height="350" />
You can type the code exactly as you see it above into a text editor, or you can use the interfaces of
software tools such as Dreamweaver, FrontPage, or GoLive to accomplish the same thing. In
Dreamweaver, alt text is added through the Properties window as pictured below:
In Microsoft's FrontPage, you double click on the image to bring up the Picture Properties dialog
box. You then add the text alternative to the Text field under Alternative representations.
Other editors have similar functions for adding alternative text. Consult your editor's documentation
for instructions on how to add an alt attribute.
Now that we have a better idea of what an alt attribute is and how simple it is to add an alt attribute
to an image, let's talk about what the alt attribute should contain.
3 de 8 31/01/2005 10:58 p.m.

5.4 How Images Are Used

Images on Web sites are used in three main ways:
1. to convey important content

2. to provide visual enhancements which offer no real content
3. to link to other areas of the site
The most appropriate alt text for an image depends on the way in which the image is used. In fact,
the same image could be used for different reasons under different circumstances, and each instance of
this image would have different alternative text. Keep the following rule in mind:
The most appropriate alt text communicates the purpose of the graphic, not its
appearance.
With that in mind, the most important information to convey in alternative text is that the user can
click on this image to go to another area of the site.
5.5 Communicating the Purpose of the Graphic

5.5.1 Images that contain important content
If the image or graphic contains information that is relevant to the content of the site, then the alt
attribute should also provide that content, in a way that is consistent with the purpose of the image.
Remember that the purpose of the image is not necessarily the same as the appearance of the image.
Example 1
For example, the WebAIM Training CD site uses images for its main navigation, such as the one
pictured below.
These images look like tabs on file folders. Some of these tabs are maroon, and others are blue.
When the tab is selected, it turns white. Part of the text is in upper case; part is in lower case. All of these
details are important to the look and feel of the Web site, but to someone who cannot see how the site
looks, its look and feel are mostly irrelevant. The important aspect of these graphics is that they link to
other areas of the site. With that in mind, I would want to provide alternative text that conveys the fact
that the user can click on this image to go to another area of the site. In this case, the link destination
would be Track 2 of the training event, which is the track for coordinators. The most appropriate alt text
for this image is as follows:
"Track 2: Coordinators."
In this case, the alt text exactly matches the text in the graphic. In most cases where there is text
within images, this is the best solution. Don't worry about describing the image. Tell the user about the
purpose of the image, not its appearance.
Example 2
Take another look at the portrait of Silvia below:
4 de 8 31/01/2005 10:58 p.m.

This particular graphic could be used in many different ways, with many different purposes. Here
are a few scenarios:
An elementary school teacher creates a Web site to explain the difference between paintings,
drawings, and sculpture. She includes several different examples of each type of art. In the text of
the page itself, she describes the differences between these three media. She uses the portrait of
Silvia as one of 4 examples of paintings. One possible alt text in this case would be "A painting of
a young lady." This is probably sufficient, as long as the teacher has adequately described what a
painting is within the document itself.
A family member is compiling a list of people in her family, along with portraits of these
individuals. Since all of the images are portraits, an appropriate alt text would be "Silvia
Alvarez."
An art instructor in a high school creates a Web site showing different types of paintings. He uses
this painting as an example of a portrait, and explains within the text of the page what a portrait is.
An appropriate alt text could be "Portrait."
An art historian is creating a catalogue of different portrait artists. His purpose is to show portraits
by various artists. The alt text could include information relevant to art historians, such as the title
of the work of art, the name of the artist, the medium, and the date. The alt text could say "Silvia
Alvarez, oil on canvas, by Paul Bohman, 2002."
We could go on with different scenarios, but I think you get the point. There is no one right alt text
for any particular image. It all depends upon the context and the purpose of the image. This is a judgment
call that the page's author must make.
5.5.1.1 Accuracy and brevity
Alternative text for images should be as accurate and as succinct as possible. Make sure that your alt
text conveys all of the important information relevant to its purpose, but don't burden users with
excessively long alt text. Screen readers or refreshable Braille devices always read the alt text, which can
make image-heavy pages rather long. If you need a longer description of the image, you should add a
longdesc tag to the image (we'll cover this in the next section).
5.5.2 Null alt text
5 de 8 31/01/2005 10:58 p.m.

5.5.2.1 Decorative images
The Web has become a graphical environment in which developers often add images to their pages
simply to enhance the visual appeal of the site. For example, the image below could be used to form part
of a rounded border on a page.
Images in this category do not provide any content to the user; they are simply used for decorative
purposes. These images have no value to someone who cannot see the page. The proper HTML markup
for this type of image is what is often referred to as an empty or null alt attribute, written as alt="". That
is alt equals quote quote, with no space in the middle. The source for the image in this example would
look like this:
<img src="corner.gif" width="84" height="90" alt="" />
Screen readers will ignore graphics with empty alt text, which is exactly what we want in this case.
You may be wondering why it is necessary to specify a null alt text. Wouldn't it make more sense to
simply leave the alt attribute off entirely? This is a good question, but the answer is that missing alt text
is worse than null alt text because some screen readers read the file name of the image, which can be
confusing to listen to. When you add null alt text, screen readers skip over the image without reading
anything at all.
Dreamweaver MX allows users to create null alt text within the Properties dialogue box.
Unfortunately, many other HTML editors do not allow you to create empty alt attributes within the
graphical interface so you must edit your HTML source code directly. To do this, locate the image in the
code and add alt="" to the image tag.
5.5.2.2 Transparent and spacer images
Developers often use transparent and spacer images to create space between elements on a page.
Although users with sight do not see the transparent images, they may be visible to individuals using text
browsers or screen readers. You should add an empty alt attribute (alt="") to all transparent and spacer
images.
5.5.2.3 Redundant images
Sometimes, Web developers add alt text to an image that is exactly the same as the text next to it, or
the same as another graphic next to it, as in the example below:
In cases like this, you should add null alt text, so that screen reader users do not have to hear the
same information twice. The JAWS screen reader would say: "image, international students; image,
international students" when reading this section of Web content, which can be confusing, or at least
annoying. (In this case, both the photograph of the girl and the adjacent text are images.)
6 de 8 31/01/2005 10:58 p.m.

5.6 Image Maps

5.6.1 Client side image maps
Every common Web development tool creates client-side image maps, rather than server-side image
maps. As the names suggest, server-side image maps require special scripting on the server, whereas
client-side image maps are processed only in the client's browser. Unless you have purposely chosen to
create a server-side image maps, you probably will never create one. Client-side image maps can be
accessible, whereas server-side image maps cannot.
Client-side image maps require alt text for both the image and the hot spots. Take a look at this
example (NOTE: none of the links lead anywhere):
There is only one image above, but there are 5 hot spots. Each of these hot spots leads to a different
location in the Web site, so it is necessary to convey the navigational purposes of each of the links. The
alt text for these hot spots should be exactly the same as the text in the image. The alt text for the hot
spots is HOME, Products, Services, Contact us, and Index. Now we have the alt text for the hot spots, but
what about the image itself? Aside from the hot spots, this image does not convey any meaningful
information. The most appropriate alt text for the image is a null alt text. Here is the code for the image
and its hot spots:
<img src="imagemap.jpg" alt="" width="199" height="303" border="0" usemap="#Map">
<map name="Map">
<area shape="rect" coords="7,9,191,54" href="#maps" alt="HOME">
<area shape="rect" coords="7,68,191,114" href="#maps" alt="Products">
<area shape="rect" coords="7,127,190,172" href="#maps" alt="Services">
<area shape="rect" coords="6,186,190,229" href="#maps" alt="Contact us">
<area shape="rect" coords="7,245,189,289" href="#maps" alt="Index">
</map>
Not all images used as image maps will have null alt text. The content author must determine the
most appropriate alt text for the situation.
5.6.2 Server-side image maps
Since there is no way to make server-side image maps accessible, the simplest advice is to not use
them. Some people are concerned that client-side image maps cannot create the geometric shapes that
they want to create, and so they use server-side image maps. The truth is that client-side image maps can
make any shape at all, as long as the developer has the patience to create all of the coordinates. Below is
an example of a client-side image map, with unusually-shaped hot spots, just to show that it can be done.
(Click on the shapes to see their outline highlighted.)
7 de 8 31/01/2005 10:58 p.m.

In effect, there is no reason to create a server-side image map.
5.7 Background Images

It is impossible to add alt text to background images, so you should put images in the
background only if they do not convey any important content.
If your background image contains important text or other visual cues, you should rewrite the
HTML so that the image is in the foreground so that you can apply the proper alt text.

8 de 8 31/01/2005 10:58 p.m.

www.webaim.org

Part 6: Long Descriptions
Part 6 Contents
When to Provide Long Descriptions
Methods of Providing a Long Description
Provide the long description in the context of the document itself
Provide a link to a long description via a normal text link
Provide a link to a long description via the longdesc attribute
Provide a link to a long description via a "d" link
6.1 When to Provide Long Descriptions

In some instances, an image is too complex to describe in a few words. Charts and graphs are
primary examples of such images. Although there does not appear to be any limit to the length of text in
an alt attribute, alt text is meant to be relatively short, so it would be an abuse of this attribute to write
more than a few words, or, at most, a few short sentences. The answer, then, is to provide a brief alt text
description of the image and then provide a longer description elsewhere.
6.2 Methods of Providing a Long Description

There are several ways of providing a long description for images. These options are listed below, in
order of most preferred to least preferred:
1. Provide the long description in the context of the document itself

2. Provide a link to a long description via a normal text link
3. Provide a link to a long description via the longdesc attribute
4. Provide a link to a long description via a "d" link
Those who are familiar with accessibility techniques may be surprised to find that the longdesc
attribute and "d" link are at the bottom of the list. The reason for this is that both methods are rather
obscure. The longdesc attribute is invisible (and inaccessible in some browsers) to people who are not
using screen readers. The "d" link is non-conventional, and can be confusing to people who are not
familiar with their purpose. The most straightforward way of making long descriptions accessible is to
make them obvious and available to everyone, whether or they have a disability or not.
6.2.1 Provide the long description in the context of the document itself
By putting the long description right in the context of the document where the graphic occurs, you
are serving everybody, not just those with disabilities. Everyone will be able to read the long description
and benefit from it. Here is an example of how that could be accomplished with an image of a graph:
1 de 3 31/01/2005 10:59 p.m.

The above bar graph shows the population of chimps in different Asian countries. The estimated
number of chimps in each country is as follows:
China: 1,545,458
Burma: 945,421
Laos: 545,845
Vietnam: 785,752
Bangladesh: 352,548
Thailand: 489,238
Cambodia: 885,465
In the above example, the data appears after the image, and is accessible to all.
6.2.2 Provide a link to a long description via a normal text link
The second-best way to provide a long description is to simply link to one. There is no fancy code
or technique involved here. Just link to a long description, as in the example below:
Text description of this graph is available on a separate page.
The information is available to everybody through this method as well, even though they have to
click on a link to access it. The link is apparent to everyone. They can choose to follow the link or not to.
6.2.3 The longdesc attribute
The longdesc attribute, which can be added to an <img> tag, does nothing more than provide a link
to a separate page where a long description is available. It works in the same way as the previous
example, except that the link is invisible to sighted readers. The following example is the same graph
with a longdesc attribute added:
2 de 3 31/01/2005 10:59 p.m.

Those who are sighted realize that there is nothing to see about a longdesc attribute. As far as they
are concerned, it isn't there. The only people who can access the longdesc attribute easily are those using
modern screen readers. Older screen readers did not support this attribute. Even among those who use the
latest version of screen reader, there are many who are unfamiliar with the longdesc attribute (because it
is used so infrequently), and do not know how to access it even though their screen reader supports it.
The bottom line is that the longdesc tag benefits only a small audience, despite the fact that it is a
technique recommended in both the WAI guidelines and the Section 508 guidelines.
Here is the markup for the longdesc attribute:
<img src="chimpgraph.gif" width="494" height="253" alt="Graph of Number of Chimps in Asia by
Location" longdesc="chimpgraphdesc.htm">
6.2.4 "D" Links.
In the days before the longdesc tag was supported by screen readers, a group of people decided that
they needed an equivalent method that was supported, so they invented the "d" link. The letter "d" stands
for "description." These "d" links are nothing more than regular links to another page, with the text of the
link being the letter "d." Here is how a "d" link would look in our example:
D
You can use an upper case D or a lower case d. It really doesn't matter. The "d" link is normally
placed right after the image. This technique works in all browsers, and it does accomplish the purpose of
providing access to the long description, but it is less elegant than the other methods. Some people will
be confused by the one-letter link. Others will simply ignore it. You can use this method, but only if you
have a good reason for rejecting the others.

3 de 3 31/01/2005 10:59 p.m.

Creating accessible images file:///d:/Microsoft/Creating%20accessible%20images.htm
www.webaim.org

Part 1: Graphics That Enhance Comprehension
Part 1 Contents
Introduction
Illustrations
Animations
Animations that distract
Animations that enhance comprehension
Icons
Video and Multimedia
Introduction
Some people think that graphics are bad for accessibility. The truth is that graphics can be of great
benefit to the accessibility of a Web page by providing illustrations, icons, animations, or other visual
cues that aid comprehension for sighted individuals. Too often we forget that when we design for people
with disabilities, we are not designing only for the blind. We must consider disabilities of all types.
Graphics can be especially useful to individuals with certain reading disabilities, learning disabilities,
attention deficit disorders, or cognitive disabilities.
1.1 Illustrations
Many concepts are communicated more effectively with the addition of illustrations. Imagine trying
to learn human anatomy from a book (or Web site) with no illustrations. How effective would it be? Here
is an example of an illustration of the muscles in the hand.
1 de 4 31/01/2005 11:02 p.m.

You will probably find it hard to imagine that a text description alone could be as understandable as
text supplemented by illustrations. The illustrations make the content more accessible to you.
Even for subjects that are not so visually-oriented, illustrations can benefit not only those with sight,
but they can be of special benefit to those with learning disabilities or reading disorders. Developers of
educational materials should especially consider the use of illustrations to enhance comprehension.
1.2 Animations
1.2.1 Animations that distract
Animations are rarely used to enhance the accessibility of Web content. Most of the time they are
simply annoying. Banner ads take advantage of the qualities of animations to purposely distract us from
the main purpose of the document. Elementary schools are notorious for their use of cute animations that
serve no real purpose, though perhaps one could argue that the animations capture the attention of the
children. While this may be true, most of these animations are actually distracting the attention of the
children from the real purpose of the page. For example, a commonly-used animation is the one of a
mailbox that opens and closes, such as the one below:
The question that you have to ask yourself is whether or not the animation is central to the page's
content. Is the purpose of the page to encourage people to send email? Perhaps, but probably not. This
type of animation is most often found at the bottom of a page that has nothing to do with sending email to
the person who wrote the page. The animation is a distraction, even when used on Web sites for children.
It would be best to eliminate this distraction.
2 de 4 31/01/2005 11:02 p.m.

1.2.2 Animations that enhance comprehension
Just because graphics are most often used to distract the viewer does not mean that they cannot
serve a more useful purpose. Animations can illustrate movements and procedures in a way that would be
difficult in text. Let's say, for instance that you want to learn a few Scottish dance steps. You could have
someone describe the steps to you in text, and perhaps this would work, but for most people, it would be
easier to see an animation of each of the steps, so that you could imitate the movements in the animation.
In the case of individuals with reading disabilities or cognitive disabilities, the benefits of animations are
even more pronounced.
Just for the sake of comparison, let's look at a text description of a Scottish dance step, then we'll
look at an animation. First the text description:
Text description: Hold your right arm over your head, bending your elbow at approximately a 45
degree angle. Put your left hand on your hip. Hop on your right foot. As you hop, alternate putting your
left foot in front of, and then in back of your right leg, but don't let your left foot touch the ground. Your
left knee should be bent as you do this. Perform a total of 4 hops on the right foot, then reverse the
position of your arms and start hopping on your right foot while your left leg performs the actions
previously performed by the right leg. After four hops on your left leg, switch back to the right leg and
switch your arms back to their original position. This time, as you hop, turn around in a circle during 4
hops until you are back where you started. Begin the procedure again.
Animation: How well do you think you were able to perform the dance step? Now try looking at an
animation of the same step.
Did the animation enhance the text description? What if you only had the animation, but not the text
description? What if you could not read the instructions at all? For those of you who do not speak
Japanese, this is easy to simulate, because the site which hosts the animation of the Scottish dancer is a
Japanese Web site. Take a look at "gallery 1" of folk dance styles on this Japanese site. Do you think that
you would be able to perform these dance steps by simply looking at the animations? Assuming that you
have sufficient vision to see the animations, the answer is probably "yes." The animations actually
enhance comprehension of the subject matter.
Of course, a text description will still be necessary for those who are blind, but we'll cover that topic
a little later.
1.3 Icons
Many computer programs use icons that either supplement or replace the text in the menu bars
(think of Microsoft Word, for example, and the icons for opening a file , printing , etc.). Here is a
set of icons from the Internet Explorer toolbar:
Here is a set of similar icons from the Opera Web browser:
The usefulness of an icon depends upon:
how well it is drawn,

how well it conveys the concept,
how well the target audience will understand the concept, and
how well the icon focuses in on the idea that it is trying to convey.
Icons need to be simple, and they need to be easily understood. Their artistic merit is really a
secondary consideration, but unattractive icons can have a negative effect on their comprehension, so
choose your artist well!
3 de 4 31/01/2005 11:02 p.m.

One of the problems with icons is that they are rarely understood in the same way by all viewers.
Most people associate a arrow that points left (such as the one below) with the concept of going back, or
going backwards, but in languages where the text proceeds from right to left, the opposite may be true.
As it turns out there really aren't any icons that are completely understood across all cultures and
languages. Even within cultures and languages, icons can be misinterpreted quite easily. Let's say that
someone decides to add an icon to a page to indicate that the items in a particular paragraph are only
speculations, and should not be regarded as generally-accepted truths. To indicate this, a question mark,
like the one below, is placed before each of these types of paragraphs
Would you immediately know what the question mark means? Probably not. If the meaning of the
question mark was explained before using it, however, the icon could be useful. You can use icons, and
they can in fact increase comprehension, but only when used wisely.
For the general population, icons can be useful, but they are not always absolutely necessary. Some
individuals with certain types of cognitive disabilities, however, must see icons in order to comprehend
the subject matter at all. Some sites are developed specifically with this population in mind. One example
can be found at www.peepo.com. Even with the illustrations and icons, these individuals will oftentimes
also require the assistance of another person at first, but can learn the iconic interface with some practice.
1.4 Video and Multimedia

Although we will not get into the details of video and multimedia right now, it should be mentioned
that these elements can also be used to enhance comprehension, in the same way that illustrations,
animations, and icons can be used. Where video is concerned, as long as you provide a text transcript (for
the blind) and captions (for the deaf), you should think of these elements as comprehension
enhancements, rather than accessibility problems. In terms of other types of multimedia, such as Flash,
the accessibility issues are a bit more complex, but it is usually possible to present the content in a way
that is accessible to people with disabilities.

4 de 4 31/01/2005 11:02 p.m.

Creating accessible tables file:///d:/Microsoft/Creating%20accessible%20tables.htm
www.webaim.org
Creating Accessible Tables

Part 1: Layout Tables
Part 1 Contents
Introduction
The Uses of Tables
Content Linearization
Checking for good table linearization
Use Proportional Sizing, Rather Than Absolute Sizing
Use the Simplest Table Configuration Possible
1.1 Introduction
If you're not a screen reader user, let's pretend that you are for just a moment. You're going to a Web
site to find out where the biology 205 class is going to be held. You go to a Web page that has this
information, and this is what you hear:
Table with 10 columns and 7 rows. Department Code, Class Number, Section, Max
Enrollment, Current Enrollment, Room Number, Days, Start Time, End Time, Instructor,
BIO, 100, 1, 15, 13, 5, Mon,Wed,Fri, 10:00, 11:00, Magde, 100, 2, 15, 7, 5, Tue,Thu, 11:00,
12:30, Indge, 205, 1, 15, 9, 6, Tue,Thu, 09:00, 10:30, Magde, 315, 1, 12, 3, 6, Mon,Wed,Fri,
13:00, 14:00, Indge, BUS, 150, 1, 15, 15, 13, Mon,Wed,Fri, 09:00, 10:00, Roberts, 210, 1,
10, 9, 13, Mon,Wed,Fri, 08:00, 09:00, Rasid.
After listening to this information, do you have any idea where biology 205 is supposed to be held?
Probably not. When you listen to tables straight through, without going into table reading mode in a
screen reader, this type of information can be quite confusing. Even when you do go into table reading
mode, it can still be confusing if the table is not marked up properly.
1.2 The Uses of Tables

There are two basic uses for tables on the Web: as data tables, and as layout tables. The original
intended use of HTML tables was for data. A table is a data table when row headers, column headers, or
both are present. For example, here is a simple data table:
Shelly's Daughters
Name Age Birthday
Jackie 5 April 5
Beth 8 January 14
In practice, tables are perhaps most commonly used for page layout. Layout tables do not have
logical headers that can be mapped to information within the table cells. Here is a simple layout table:
1 de 6 31/01/2005 11:03 p.m.

Thoughts by Benjamin
Franklin
Read these first:

"Those who love deeply never Read this second:
grow old; they may die of old age, "Blessed is he who expects
but they die young." nothing, for he shall never be
"Hide not your talents. They for disappointed."
use were made. What's a sundial in "When you're finished
the shade." changing, you're finished."
You will probably hear some accessibility advocates say that layout tables are a bad idea, and that
CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using
tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of
disabilities can easily access tables, as long as the tables are designed with accessibility in mind.
1.3 Content Linearization

Content linearization refers to the order of the content when all formatting is removed. If we remove
the table from the Benjamin Franklin quotes, this is the linearized reading order that we get:
Thoughts by Benjamin Franklin

Read these second:
"Blessed is he who expects nothing, for he shall never be disappointed."
"If a man empties his purse into his head, no man can take it away from him. An investment in
knowledge always pays the best interest."
"When you're finished changing, you're finished."
Read these first:
"Those who love deeply never grow old; they may die of old age, but they die young."
"Hide not your talents. They for use were made. What's a sundial in the shade."
You may not have noticed this, but the quotes on the right hand side were read before the quotes on
the left hand side. In the linearized reading order of this particular table, we ended up reading the items in
the wrong order. This result is probably contrary to the order you thought the content would be read in.
When you look at the table, you visually scan from left to right. In this case, though, the right side is read
before the left side. This is due to the spanned rows and columns that comprise this table. The table is not
2 de 6 31/01/2005 11:03 p.m.

so straightforward when you look at the code.

Most sites on the Internet use tables for layout, and most of them use spanned rows and columns to
achieve formatting effects. The end result is that the linearized reading order may not be the same as the
visual reading order. This can lead to confusion on the part of people who access the linearized reading
order, such as individuals who use screen readers.
Screen readers essentially ignore the fact that the content is inside of a table. The screen reader just
reads the content in the literal order that it appears in the code. If the literal order of the content in the
code is logical, then your linearized reading order is logical.
Screen readers read the content of Web pages as if there were no HTML tags at all.
They read everything in the order that it appears in the source markup.
This is an important concept. Let's take a look at another circumstance in which this becomes an
issue. Here is a table which was created for visual effect:
Basement UP!
Toilets
Flush
Must
The visual user will read: "Basement Toilets Must Flush UP!"
The screen reader will hear (or feel via Braille): "Basement UP! Toilets Flush Must"
Why does this difference exist between the visual order and the screen reader order? To answer this
question, we have to look at the table structure. Here is the same table with the border added back in.
Numbers have also been added to each cell to indicate the order in which the screen reader will read
them:
1 - Basement 2 3 4 - UP!
5 - Toilets
7 - Flush 8
6
9 10 - Must 11 12
Here is the markup code for the original table. Notice the order of the text:
<table border="0" style="/*/*/background-color:#ffffcc">
<tr>
<td><span
style="/*/*/font-size:120%;font-weight:bold;">Basement</span></td>
<td> </td>
<td> </td>
<td><span
style="/*/*/font-size:120%;font-weight:bold;">UP!</span></td>
3 de 6 31/01/2005 11:03 p.m.

</tr>
<tr>
<td valign="top"><span
style="/*/*/font-size:120%;font-weight:bold;">Toilets</span></td>
<td><img src="/media/graphics/tutorials/tables/toilet.jpg" alt="a
toilet" width="118" height="144"></td>
<td><span
style="/*/*/font-size:120%;font-weight:bold;">Flush</span></td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> <div style="/*/*/text-align:right"><span
style="font-size:120%;font-weight:bold;">Must</span></div></td>
<td> </td>
<td> </td>
</tr>
</table>
1.3.1 Checking for good table linearization
There are a couple of good ways to check to see if your tables linearize well. The first one is to use
the online accessibility validator, the WAVE.
Here is the same table, as seen through the WAVE:
The red, yellow, and blue icon at the top indicates that the WAVE has detected that this table is
being used as a layout table, since there is no additional markup as would be required for data tables.
Notice that the WAVE has added little blue arrows to show the reading order of the table cells in this
table. The WAVE has also added an icon to show us the alt text for the image of the toilet. By paying
close attention to the numbers in the table, you can check to make sure that the reading order is logical.
You can also turn off the tables entirely when using the WAVE by setting your preferences to
exclude tables.
4 de 6 31/01/2005 11:03 p.m.

Another way to check the reading order of table cells is to use the Opera browser
(www.opera.com).Opera allows the user to turn off tables completely.
In Opera 7, select User Mode > Disable tables.
In Opera 6.0, go to File > Preferences > Page Style > User Mode then de-select the Tables option.
Once you have done this, you can toggle the User Mode on and off with one click of the mouse. The
User Mode icon is found in the upper left area of the browser window, right next to the address bar. It
looks like a sheet of paper.
You'll also notice that the user mode turns off colors and styles. That's because it's using your style
sheet, which, if you haven't specified one, is no style sheet at all. When you strip the page of tables and
styles, you have a pretty good idea of what a page is like for users of screen readers.
1.4 Header Tags
5 de 6 31/01/2005 11:03 p.m.

When you use the table header (<th>) tag, most browsers cause the text to become bold and
centered, which can be a nice visual effect, but the <th> tag should only be used in data tables. Don't use
it in layout tables because you may confuse screen reader users, making them think they're inside a data
table when they are not.
1.5 Use Proportional Sizing, Rather Than Absolute Sizing

Internet documents and Web pages are different than their ink-on-paper counterparts. Printed pages
have an absolute, unchangeable size. Web pages do not. We can stretch our browser window up, down,
right, left and achieve just about any size. Web layout should be fluid to fit the fluid nature of the Web
browser.
A layout table with a fixed width does not change its size to match the viewing area of the browser
window. If the viewing area is very small, users will be required to scroll back and forth too much. This
can be quite a nuisance for people with low vision who must use special software to enlarge the viewing
area. This software, often called screen enlarger software, can enlarge the contents of the screen much
more than the operating system can. Some people have the magnification so high that only a word or two
can be seen at a time. More commonly, users will set the magnification between 200% and 500%.
Developers can use the Opera browser to simulate the effect of using a screen magnifier.
Opera can enlarge Web pages up to 1000%! The magnification option is found in the upper
right of the document window. When you enlarge pages, you will notice that the amount of
horizontal scrolling increases significantly. You can't avoid this, but you can reduce its
impact by specifying relative table layout units, such as percentages, rather than fixed units,
such as pixels.
1.6 Use the Simplest Table Configuration Possible

Some designers go crazy with layout tables. They create all kinds of unnecessary rows and columns,
using spanned rows and columns in every which way, until the table hardly looks like a table at all
anymore. All of this may be invisible to sighted users if the table border is set to zero, but blind users will
"see" it all. Their screen readers will inform them of the number of rows and columns in the table. When
they try to navigate from one area to the other within the table, they may become disoriented. The rule of
thumb here is, the simpler the better.

6 de 6 31/01/2005 11:03 p.m.

Part 2: Creating accessible tables file:///d:/Microsoft/Creating%20Accessible%20Tables2.htm
www.webaim.org

Part 2: Data Tables
Part 2 Contents
Marking Up Data Tables
Designate Row and Column Headers Using the <th> Tag
Associate the Data Cells with the Appropriate Headers
scope
headers and "id"
Use Proportional Sizing, Rather than Absolute Sizing
Provide Names or Titles for Data Tables Using the <caption> Tag
Provide Summaries Using the Summary Attribute
Avoid Spanned Rows or Columns
Avoid Tables with More than Two Levels of Row and/or Column Headers
2.1 Marking Up Data Tables

Data tables are different from layout tables. The purpose of data tables is to present information in a
grid, or matrix, and to have column or rows that show the meaning of the information in the grid.
When screen readers read straight through data tables--especially large ones--it's easy for users to
get lost, as you may remember from the first page of this tutorial.
In order for a data table to be accessible, it must have the proper markup in the HTML. When the
proper HTML markup is in place, users of screen readers can navigate through data tables one cell at a
time, and they will hear the column and row headers spoken to them.
2.2 Designate Row and Column Headers Using the <th>

Tag
The very first step toward creating an accessible data table is to designate row and/or column
headers. This is easy enough to do. Most authoring tools provide a method of changing data cells into
header cells. In the markup, the <td> tag is used for table data cells and the <th> tag is used for table
header cells. Going back to our original data table example, the column headers for this table are Name,
Age, and Birthday. The row headers are Jackie and Beth.
Shelly's Daughters
Name Age Birthday
Jackie 5 April 5
Beth 8 January 14
1 de 4 31/01/2005 11:04 p.m.

2.3 Associate the Data Cells with the Appropriate Headers

Now that we've created headers, we need to associate the cells with the appropriate headers. There
are two ways to do associate data cells with their headers.
2.3.1 Scope
The scope attribute should be used on simple data tables such as the one in this example. Here is the
markup for the table, using the scope attribute:
<table border="1" align="center">
<caption>Shelly's Daughters</caption>
<tr>
<th scope="col">Name</th>
<th scope="col">Age</th>
<th scope="col">Birthday</th>
</tr>
<tr>
<th scope="row">Jackie</th>
<td>5</td>
<td>April 5</td>
</tr>
<tr>
<th scope="row">Beth</th>
<td>8</td>
<td>January 14</td>
</tr>
</table>
The scope tag tells the browser and screen reader that everything under the column is related to the
header at the top, and everything to the right of the row header is related to that header. It's a
straightforward concept.
2.3.2 Headers and "id"
Another way to accomplish the same purpose is to use the "headers" and "id" attributes. This
method is NOT recommended for simple tables such as the first example. The "headers" and "id"
method should only be used when there is more than one logical level in a table, and when it is necessary
to link more than two headers with a data cell. If we extend our original example, we can create a table
that fits this criterion. In the tsable below, data have three headers each, so it is appropriate to use a more
complex technique.
Shelly's Daughters
Name Age Birthday
Jackie 5 April 5
by birth
Beth 8 January 14
by marriage Jenny 12 Feb 12
The markup looks like this:
<table border="1">
<caption>
Shelly's Daughters
</caption>
<tr>
<td> </td>
<th id="name">Name</th>
2 de 4 31/01/2005 11:04 p.m.

<th id="age">Age</th>
<th id="birthday">Birthday</th>
</tr>
<tr>
<th rowspan="2" id="birth">by birth</th>
<th id="jackie">Jackie</th>
<td headers="birth jackie age">5</td>
<td headers="birth jackie birthday">April 5</td>
</tr>
<tr>
<th id="beth">Beth</th>
<td headers="birth beth age">8</td>
<td headers="birth beth birthday">January 14</td>
</tr>
<tr>
<th id="step">by marriage</th>
<th id="jenny">Jenny</th>
<td headers ="step jenny age">12</td>
<td headers="step jenny birthday">Feb 12</td>
</tr>
</table>
Again, it should be emphasized that this method is more complex. It should be used with tables of a
more complex nature, where the scope attribute will not work.
Another caveat: spanned rows and columns are not handled well by the JAWS screen reader, which
is the most popular brand of screen reader. If at all possible, avoid complex data tables, or represent the
data in a way that is less complex, preferably with no more than two headings applying to a single data
cell.
2.4 Use Proportional Sizing, Rather than Absolute Sizing

The rule that applies to layout tables also applies to data tables. Let the browser window determine
the width of the table whenever possible, to reduce the horizontal scrolling required of those with low
vision.
2.5 Provide Names or Titles for Data Tables Using the

<caption> Tag
Tables ought to have some sort of title or caption to them. This is properly done by using the caption
tag, right after the opening <table> tag, like this:
It is not absolutely necessary to have caption tags on every data table for the sake of accessibility,
but it is still a good practice.
2.6 Provide Summaries Using the Summary Attribute

This guideline is not a requirement for simple tables, but can increase the comprehension of more
complex tables for people using screen readers. A complex table of weather data might have a summary
that says:
"A warming trend has been observed in Cache Valley, with temperatures about 5
degrees above historical averages over the last two months, with the highest temperature
3 de 4 31/01/2005 11:04 p.m.

difference being 25 degrees above average."
Such a description would highlight the important elements of a table, and help the user to know
what to look for in the data.
Some accessibility advocates insist that ALL tables have summaries, including data tables. The truth
is that this approach is not worth the effort. It is not necessary for screen readers to hear the words "This
table used for layout purposes only" at the beginning of every table on a site. Some sites use so many
tables, that the added text would only cause confusion, and lengthen the time it takes to listen to the page.
A better approach is to only use table summaries when they perform the service that they were designed
to perform: to provide brief summaries of complex data.
2.7 Avoid Spanned Rows or Columns

Note: The following information pertains to older versions of the JAWS screen reader.
Newer versions of JAWS do not have the flaw explained below.
I wish that I could tell you that all screen readers do exactly what they're supposed to.
Unfortunately, one of the most popular screen readers on the market, JAWS, does not read the tables
with spanned cells well at all, even when correct markup is used to associate data cells with their
corresponding headers. As it turns out, JAWS handles spanned rows in tables very poorly. Let's look at
an example of a table that spans more than one row:
View table
The above table uses spanned rows in two instances: for the two cells on the left which contain the
department codes BIO and BUS (which stand for biology and business, by the way). JAWS gets very
confused with these spanned rows, and actually associates the WRONG headers with the data cells
below. This means that the user will hear such nonsensical things as "Room number: Tue, Thu" and
"Days: 11:00."
Don't despair. There are things that can be done to avoid totally confusing the users of screen
readers, even if they are only work-arounds to make up for the programming deficits in JAWS.
Work-around #1
Make duplicate cells within the table, rather than one single row-spanned cell. See what workaround
#1 would look like.
Work-around #2
We could also combine the first two columns into one. See what workaround #2 would look like.
2.8 Avoid Tables with More than Two Levels of Row and/or
Column Headers
There are methods of marking up tables of greater complexity than those discussed here. Some
screen readers can read this markup and render the content accurately. The sad truth is that the most
popular screen reader, JAWS, cannot do so reliably. If at all possible, use simple, one- or
two-dimensional tables without spanned rows or columns. That is the safest bet.

4 de 4 31/01/2005 11:04 p.m.

www.webaim.org

Part 1: Layout Tables
Part 1 Contents
Introduction
The Uses of Tables
Content Linearization
Checking for good table linearization
Use Proportional Sizing, Rather Than Absolute Sizing
Use the Simplest Table Configuration Possible
1.1 Introduction
If you're not a screen reader user, let's pretend that you are for just a moment. You're going to a Web
site to find out where the biology 205 class is going to be held. You go to a Web page that has this
information, and this is what you hear:
Table with 10 columns and 7 rows. Department Code, Class Number, Section, Max
Enrollment, Current Enrollment, Room Number, Days, Start Time, End Time, Instructor,
BIO, 100, 1, 15, 13, 5, Mon,Wed,Fri, 10:00, 11:00, Magde, 100, 2, 15, 7, 5, Tue,Thu, 11:00,
12:30, Indge, 205, 1, 15, 9, 6, Tue,Thu, 09:00, 10:30, Magde, 315, 1, 12, 3, 6, Mon,Wed,Fri,
13:00, 14:00, Indge, BUS, 150, 1, 15, 15, 13, Mon,Wed,Fri, 09:00, 10:00, Roberts, 210, 1,
10, 9, 13, Mon,Wed,Fri, 08:00, 09:00, Rasid.
After listening to this information, do you have any idea where biology 205 is supposed to be held?
Probably not. When you listen to tables straight through, without going into table reading mode in a
screen reader, this type of information can be quite confusing. Even when you do go into table reading
mode, it can still be confusing if the table is not marked up properly.
1.2 The Uses of Tables

There are two basic uses for tables on the Web: as data tables, and as layout tables. The original
intended use of HTML tables was for data. A table is a data table when row headers, column headers, or
both are present. For example, here is a simple data table:
Shelly's Daughters
Name Age Birthday
Jackie 5 April 5
Beth 8 January 14
In practice, tables are perhaps most commonly used for page layout. Layout tables do not have
logical headers that can be mapped to information within the table cells. Here is a simple layout table:
1 de 6 31/01/2005 11:03 p.m.

Thoughts by Benjamin
Franklin
Read these first:

"Those who love deeply never Read this second:
grow old; they may die of old age, "Blessed is he who expects
but they die young." nothing, for he shall never be
"Hide not your talents. They for disappointed."
use were made. What's a sundial in "When you're finished
the shade." changing, you're finished."
You will probably hear some accessibility advocates say that layout tables are a bad idea, and that
CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using
tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of
disabilities can easily access tables, as long as the tables are designed with accessibility in mind.
1.3 Content Linearization

Content linearization refers to the order of the content when all formatting is removed. If we remove
the table from the Benjamin Franklin quotes, this is the linearized reading order that we get:
Thoughts by Benjamin Franklin

Read these second:
"Blessed is he who expects nothing, for he shall never be disappointed."
"If a man empties his purse into his head, no man can take it away from him. An investment in
knowledge always pays the best interest."
"When you're finished changing, you're finished."
Read these first:
"Those who love deeply never grow old; they may die of old age, but they die young."
"Hide not your talents. They for use were made. What's a sundial in the shade."
You may not have noticed this, but the quotes on the right hand side were read before the quotes on
the left hand side. In the linearized reading order of this particular table, we ended up reading the items in
the wrong order. This result is probably contrary to the order you thought the content would be read in.
When you look at the table, you visually scan from left to right. In this case, though, the right side is read
before the left side. This is due to the spanned rows and columns that comprise this table. The table is not
2 de 6 31/01/2005 11:03 p.m.

so straightforward when you look at the code.

Most sites on the Internet use tables for layout, and most of them use spanned rows and columns to
achieve formatting effects. The end result is that the linearized reading order may not be the same as the
visual reading order. This can lead to confusion on the part of people who access the linearized reading
order, such as individuals who use screen readers.
Screen readers essentially ignore the fact that the content is inside of a table. The screen reader just
reads the content in the literal order that it appears in the code. If the literal order of the content in the
code is logical, then your linearized reading order is logical.
Screen readers read the content of Web pages as if there were no HTML tags at all.
They read everything in the order that it appears in the source markup.
This is an important concept. Let's take a look at another circumstance in which this becomes an
issue. Here is a table which was created for visual effect:
Basement UP!
Toilets
Flush
Must
The visual user will read: "Basement Toilets Must Flush UP!"
The screen reader will hear (or feel via Braille): "Basement UP! Toilets Flush Must"
Why does this difference exist between the visual order and the screen reader order? To answer this
question, we have to look at the table structure. Here is the same table with the border added back in.
Numbers have also been added to each cell to indicate the order in which the screen reader will read
them:
1 - Basement 2 3 4 - UP!
5 - Toilets
7 - Flush 8
6
9 10 - Must 11 12
Here is the markup code for the original table. Notice the order of the text:
<table border="0" style="/*/*/background-color:#ffffcc">
<tr>
<td><span
style="/*/*/font-size:120%;font-weight:bold;">Basement</span></td>
<td> </td>
<td> </td>
<td><span
style="/*/*/font-size:120%;font-weight:bold;">UP!</span></td>
3 de 6 31/01/2005 11:03 p.m.

</tr>
<tr>
<td valign="top"><span
style="/*/*/font-size:120%;font-weight:bold;">Toilets</span></td>
<td><img src="/media/graphics/tutorials/tables/toilet.jpg" alt="a
toilet" width="118" height="144"></td>
<td><span
style="/*/*/font-size:120%;font-weight:bold;">Flush</span></td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> <div style="/*/*/text-align:right"><span
style="font-size:120%;font-weight:bold;">Must</span></div></td>
<td> </td>
<td> </td>
</tr>
</table>
1.3.1 Checking for good table linearization
There are a couple of good ways to check to see if your tables linearize well. The first one is to use
the online accessibility validator, the WAVE.
Here is the same table, as seen through the WAVE:
The red, yellow, and blue icon at the top indicates that the WAVE has detected that this table is
being used as a layout table, since there is no additional markup as would be required for data tables.
Notice that the WAVE has added little blue arrows to show the reading order of the table cells in this
table. The WAVE has also added an icon to show us the alt text for the image of the toilet. By paying
close attention to the numbers in the table, you can check to make sure that the reading order is logical.
You can also turn off the tables entirely when using the WAVE by setting your preferences to
exclude tables.
4 de 6 31/01/2005 11:03 p.m.

Another way to check the reading order of table cells is to use the Opera browser
(www.opera.com).Opera allows the user to turn off tables completely.
In Opera 7, select User Mode > Disable tables.
In Opera 6.0, go to File > Preferences > Page Style > User Mode then de-select the Tables option.
Once you have done this, you can toggle the User Mode on and off with one click of the mouse. The
User Mode icon is found in the upper left area of the browser window, right next to the address bar. It
looks like a sheet of paper.
You'll also notice that the user mode turns off colors and styles. That's because it's using your style
sheet, which, if you haven't specified one, is no style sheet at all. When you strip the page of tables and
styles, you have a pretty good idea of what a page is like for users of screen readers.
1.4 Header Tags
5 de 6 31/01/2005 11:03 p.m.

When you use the table header (<th>) tag, most browsers cause the text to become bold and
centered, which can be a nice visual effect, but the <th> tag should only be used in data tables. Don't use
it in layout tables because you may confuse screen reader users, making them think they're inside a data
table when they are not.
1.5 Use Proportional Sizing, Rather Than Absolute Sizing

Internet documents and Web pages are different than their ink-on-paper counterparts. Printed pages
have an absolute, unchangeable size. Web pages do not. We can stretch our browser window up, down,
right, left and achieve just about any size. Web layout should be fluid to fit the fluid nature of the Web
browser.
A layout table with a fixed width does not change its size to match the viewing area of the browser
window. If the viewing area is very small, users will be required to scroll back and forth too much. This
can be quite a nuisance for people with low vision who must use special software to enlarge the viewing
area. This software, often called screen enlarger software, can enlarge the contents of the screen much
more than the operating system can. Some people have the magnification so high that only a word or two
can be seen at a time. More commonly, users will set the magnification between 200% and 500%.
Developers can use the Opera browser to simulate the effect of using a screen magnifier.
Opera can enlarge Web pages up to 1000%! The magnification option is found in the upper
right of the document window. When you enlarge pages, you will notice that the amount of
horizontal scrolling increases significantly. You can't avoid this, but you can reduce its
impact by specifying relative table layout units, such as percentages, rather than fixed units,
such as pixels.
1.6 Use the Simplest Table Configuration Possible

Some designers go crazy with layout tables. They create all kinds of unnecessary rows and columns,
using spanned rows and columns in every which way, until the table hardly looks like a table at all
anymore. All of this may be invisible to sighted users if the table border is set to zero, but blind users will
"see" it all. Their screen readers will inform them of the number of rows and columns in the table. When
they try to navigate from one area to the other within the table, they may become disoriented. The rule of
thumb here is, the simpler the better.

6 de 6 31/01/2005 11:03 p.m.

www.webaim.org

Part 2: Data Tables
Part 2 Contents
Marking Up Data Tables
Designate Row and Column Headers Using the <th> Tag
Associate the Data Cells with the Appropriate Headers
scope
headers and "id"
Use Proportional Sizing, Rather than Absolute Sizing
Provide Names or Titles for Data Tables Using the <caption> Tag
Provide Summaries Using the Summary Attribute
Avoid Spanned Rows or Columns
Avoid Tables with More than Two Levels of Row and/or Column Headers
2.1 Marking Up Data Tables

Data tables are different from layout tables. The purpose of data tables is to present information in a
grid, or matrix, and to have column or rows that show the meaning of the information in the grid.
When screen readers read straight through data tables--especially large ones--it's easy for users to
get lost, as you may remember from the first page of this tutorial.
In order for a data table to be accessible, it must have the proper markup in the HTML. When the
proper HTML markup is in place, users of screen readers can navigate through data tables one cell at a
time, and they will hear the column and row headers spoken to them.
2.2 Designate Row and Column Headers Using the <th>

Tag
The very first step toward creating an accessible data table is to designate row and/or column
headers. This is easy enough to do. Most authoring tools provide a method of changing data cells into
header cells. In the markup, the <td> tag is used for table data cells and the <th> tag is used for table
header cells. Going back to our original data table example, the column headers for this table are Name,
Age, and Birthday. The row headers are Jackie and Beth.
Shelly's Daughters
Name Age Birthday
Jackie 5 April 5
Beth 8 January 14
1 de 4 31/01/2005 11:04 p.m.

2.3 Associate the Data Cells with the Appropriate Headers

Now that we've created headers, we need to associate the cells with the appropriate headers. There
are two ways to do associate data cells with their headers.
2.3.1 Scope
The scope attribute should be used on simple data tables such as the one in this example. Here is the
markup for the table, using the scope attribute:
<tr>
<th scope="col">Name</th>
<th scope="col">Age</th>
<th scope="col">Birthday</th>
</tr>
<tr>
<th scope="row">Jackie</th>
<td>5</td>
<td>April 5</td>
</tr>
<tr>
<th scope="row">Beth</th>
<td>8</td>
<td>January 14</td>
</tr>
</table>
The scope tag tells the browser and screen reader that everything under the column is related to the
header at the top, and everything to the right of the row header is related to that header. It's a
straightforward concept.
2.3.2 Headers and "id"
Another way to accomplish the same purpose is to use the "headers" and "id" attributes. This
method is NOT recommended for simple tables such as the first example. The "headers" and "id"
method should only be used when there is more than one logical level in a table, and when it is necessary
to link more than two headers with a data cell. If we extend our original example, we can create a table
that fits this criterion. In the tsable below, data have three headers each, so it is appropriate to use a more
complex technique.
Shelly's Daughters
Name Age Birthday
Jackie 5 April 5
by birth
Beth 8 January 14
by marriage Jenny 12 Feb 12
The markup looks like this:
<table border="1">
<caption>
Shelly's Daughters
</caption>
<tr>
<td> </td>
<th id="name">Name</th>
2 de 4 31/01/2005 11:04 p.m.

<th id="age">Age</th>
<th id="birthday">Birthday</th>
</tr>
<tr>
<th rowspan="2" id="birth">by birth</th>
<th id="jackie">Jackie</th>
<td headers="birth jackie age">5</td>
<td headers="birth jackie birthday">April 5</td>
</tr>
<tr>
<th id="beth">Beth</th>
<td headers="birth beth age">8</td>
<td headers="birth beth birthday">January 14</td>
</tr>
<tr>
<th id="step">by marriage</th>
<th id="jenny">Jenny</th>
<td headers ="step jenny age">12</td>
<td headers="step jenny birthday">Feb 12</td>
</tr>
</table>
Again, it should be emphasized that this method is more complex. It should be used with tables of a
more complex nature, where the scope attribute will not work.
Another caveat: spanned rows and columns are not handled well by the JAWS screen reader, which
is the most popular brand of screen reader. If at all possible, avoid complex data tables, or represent the
data in a way that is less complex, preferably with no more than two headings applying to a single data
cell.
2.4 Use Proportional Sizing, Rather than Absolute Sizing

The rule that applies to layout tables also applies to data tables. Let the browser window determine
the width of the table whenever possible, to reduce the horizontal scrolling required of those with low
vision.
2.5 Provide Names or Titles for Data Tables Using the

<caption> Tag
Tables ought to have some sort of title or caption to them. This is properly done by using the caption
tag, right after the opening <table> tag, like this:
It is not absolutely necessary to have caption tags on every data table for the sake of accessibility,
but it is still a good practice.
2.6 Provide Summaries Using the Summary Attribute

This guideline is not a requirement for simple tables, but can increase the comprehension of more
complex tables for people using screen readers. A complex table of weather data might have a summary
that says:
"A warming trend has been observed in Cache Valley, with temperatures about 5
degrees above historical averages over the last two months, with the highest temperature
3 de 4 31/01/2005 11:04 p.m.

difference being 25 degrees above average."
Such a description would highlight the important elements of a table, and help the user to know
what to look for in the data.
Some accessibility advocates insist that ALL tables have summaries, including data tables. The truth
is that this approach is not worth the effort. It is not necessary for screen readers to hear the words "This
table used for layout purposes only" at the beginning of every table on a site. Some sites use so many
tables, that the added text would only cause confusion, and lengthen the time it takes to listen to the page.
A better approach is to only use table summaries when they perform the service that they were designed
to perform: to provide brief summaries of complex data.
2.7 Avoid Spanned Rows or Columns

Note: The following information pertains to older versions of the JAWS screen reader.
Newer versions of JAWS do not have the flaw explained below.
I wish that I could tell you that all screen readers do exactly what they're supposed to.
Unfortunately, one of the most popular screen readers on the market, JAWS, does not read the tables
with spanned cells well at all, even when correct markup is used to associate data cells with their
corresponding headers. As it turns out, JAWS handles spanned rows in tables very poorly. Let's look at
an example of a table that spans more than one row:
View table
The above table uses spanned rows in two instances: for the two cells on the left which contain the
department codes BIO and BUS (which stand for biology and business, by the way). JAWS gets very
confused with these spanned rows, and actually associates the WRONG headers with the data cells
below. This means that the user will hear such nonsensical things as "Room number: Tue, Thu" and
"Days: 11:00."
Don't despair. There are things that can be done to avoid totally confusing the users of screen
readers, even if they are only work-arounds to make up for the programming deficits in JAWS.
Work-around #1
Make duplicate cells within the table, rather than one single row-spanned cell. See what workaround
#1 would look like.
Work-around #2
We could also combine the first two columns into one. See what workaround #2 would look like.
2.8 Avoid Tables with More than Two Levels of Row and/or
Column Headers
There are methods of marking up tables of greater complexity than those discussed here. Some
screen readers can read this markup and render the content accurately. The sad truth is that the most
popular screen reader, JAWS, cannot do so reliably. If at all possible, use simple, one- or
two-dimensional tables without spanned rows or columns. That is the safest bet.

4 de 4 31/01/2005 11:04 p.m.

Creating accessible forms file:///d:/Microsoft/Creating%20accessible%20forms.htm
www.webaim.org
Creating Accessible Forms

Part 1: General Form Accessibility
Part 1 Contents
Introduction
Ensure Forms are Keyboard Accessible, Logical, and Easy to Use
1.1 Introduction
On the Web, there are two primary means for receiving information from a Web site - e-mail and
forms. E-mail typically does not pose any major accessibility problems and allowing Web site users
access to a contact e-mail address is a great usability and accessibility tool. Forms often provide a better
means of communication. Forms can be submitted easily and do not require an e-mail program or Web
service. With forms, one can also get the specific information needed. Forms can also pose accessibility
problems.
When we talk about the accessibility of forms, we are usually referring about their accessibility to
screen readers and the visually impaired. People with other types of disabilities generally are less
affected by faulty forms that are missing some of the HTML accessibility features. It should be noted,
however, that everyone benefits from a well-organized form, especially those with cognitive disabilities.
Visual layout can be important to those who have sight. The less explanation that a form needs, the
better. Still, the focus of this exercise is mainly to make a form that can be read by a screen reader.
1.2 Ensure Forms are Keyboard Accessible, Logical, and

Easy to Use
Many users must use their keyboard to navigate and use the Web. You must ensure that the forms
on your Web site can be completed using only the keyboard. Few things can make forms totally unusable
with the keyboard. The most common of which is JavaScript. Be careful in your use of JavaScript to
manipulate form data, set focus, change form elements, or submit forms. Each of these can make the
form difficult or impossible to complete or understand using the keyboard alone. Always test your Web
site forms for accessibility.
A use of forms that has become common on the Web is the drop-down menu for navigation. It
allows you to put many navigational items into a very small amount of real estate in your page. User's
can select the drop-down menu to select an item that corresponds with a location on the Web. While
these forms by themselves do not cause accessibility issues, if JavaScript is used to submit the form data
when the user selects a drop-down menu item, then accessibility is affected. These forms often use the
JavaScript onChange event, which means that when the form items is changed, the browser is instructed
to automatically go to a specific Web page. This onChange event is triggered when the user releases their
mouse button after selecting the item in the drop-down menu that they want. If, however, the user is not
using a mouse, they must use the keyboard arrows to navigate through the drop-down menu items. Each
time they move up or down through the menu's items, the JavaScript detects an onChange event, which
directs the browser to a new page. An example of this form can be found at
http://sports.espn.go.com/ncb/index by trying to select a conference from the menu on the left of the
1 de 2 31/01/2005 11:06 p.m.

Creating accessible forms file:///d:/Microsoft/Creating%20accessible%20forms.htm
page. So, if the drop-down menu has ten items, and the user wants to get to the tenth item, they will be
forced to first select the first item, which will take them to a Web page, go back to the previous page,
select the next item, go back to the previous page, and so on, ten times until they get to the page they
want. Solution: do not use JavaScript to automatically change the location of the Web browser. Instead,
allow the user to select the menu item then select an adjacent form button to go to the page for the item
they have selected.
Forms should also be organized in a logical manner. Place the label for the form (e.g., First Name:)
adjacent to the form element (i.e., text box, check box, radio button, menu/list). Provide good and clear
instructions about what information is desired. If any form elements are required, be sure to indicate so.
Make sure that the order in which form elements are accessed is logical and easy. This can sometimes by
problematic if tables are used to control layout of form items. To check the linearized order of items on
the page, use the Wave accessibility tool or the Opera browser (see the article Using Opera to Check for
Accessibility).
Now that we've learned how to increase the accessibility of forms for all users, let's learn specific
techniques that will help screen reader users.

2 de 2 31/01/2005 11:06 p.m.

Part 2: Creating accessible forms file:///d:/Microsoft/Creating%20accessible%20forms2.htm
www.webaim.org

Part 2: Screen Reader Form Accessibility
Part 2 Contents
Key Concepts
Provide a Logical Form Layout
Using Form Labels Appropriately
2.1 Key Concepts

Place form labels next to their corresponding form controls.
Provide markup for labels, using the <label> tag.
Group related form elements using the <fieldset> tag.
Provide a title or "legend" for each field set using the <legend> tag.
Group radio buttons in a <fieldset> tag, and provide a <label> for each checkbox.
Group checkboxes in a fieldset tag, and provide a <label> for each checkbox.
Always provide a button to submit forms. Don't use JavaScript to automatically submit them.
2.2 Provide a Logical Form Layout

One of the most common ways of navigating through a form is using the tab key. A person fills in
one field, hits the tab key, fills in the next field, and so on, until the end of the form is reached. For visual
users, this is an easy thing, because the labels are placed in such a way that they appear to be linked to
their corresponding controls. For a blind person using a screen reader, however, visual layout is not
going to be of much help. There has to be some way of linking the label with its control in the markup.
Let me give an example to demonstrate the possible confusion that can occur with a form that is poorly
marked-up and poorly organized.
[skip over confusing table]
First Name Email Home Phone
Middle Initial Computer type Work Phone
Last Name j
k
l
m
n Mac n
j PC
k
l
m Country
Internet speed n
j 28.8 n
k
l
m j 56k n
k
l
m j T1
k
l
m
Visually, this table makes at least some sense (even if it is a bit confusing). For the most part, a
person with sight can figure out that the First Name label goes with the control beneath it, and that the
Email label goes with the control to the right of it. What happens when we remove the colors and strip it
of its formatting, though? A screen reader will read the above table in this order:
1 2 3
1 de 3 31/01/2005 11:06 p.m.

4 5 6 7
8 9 10 11
12 13 14
Even though a screen reader will not render the colors that have been shown, they were left in for
comparison purposes. If you compare the reading order to the visual order in the table above it, you can
see that the labels and the form elements do not match up very well. The person using the screen reader
is likely to become very confused, and may fill in the form incorrectly, typing information in the wrong
places.
Let's hear what the form sounds like to a screen reader:
Jaws, reading the form straight through. Choose a format: WAV | MP3 | RealAudio | Read
Transcript
Jaws, using the tab key. Choose a format: WAV | MP3 | RealAudio | Read Transcript
2.3 Using Form Labels Appropriately

There are two things that we can do to the previous table to fix it:
1. Put the labels adjacent to their controls

2. Use HTML markup to associate the controls explicitly with their labels
One way to fix the accessibility problems of the above table would be to reduce the table to two
columns, placing the labels directly to the left of the form elements, then adding in the appropriate
HTML tags (see the HTML markup on the next page):
First Name
Last Name
Middle Initial
Home Phone
Work Phone
Country
Computer Type Internet Speed
j Mac
k
l
m
n j
k
l
m
n 28.8
j PC
k
l
m
n j 56k
k
l
m
n
j Linux
k
l
m
n j T1
k
l
m
n
2.3.1 Create labels for form elements using the <label> tag
When a screen reader user is navigating through form elements on a Web page, the screen reader
software will identify the type of form element that is currently selected and will provide them means to
complete, select, de-select, or submit that form element. However, when navigating through the form,
there is often no indication as to what information is desired with the particular form item. For instance,
if the user navigates to a text box using the tab key, there may be no indication as to whether the text box
is where they should submit their name, address, phone number, a message, or any number of other
things. This can be solved by associating form labels to form items on the page. The label should almost
always be located adjacent to the form item itself. Specific details on how to associate labels with form
2 de 3 31/01/2005 11:06 p.m.

items can be found in Part 4. When a screen reader accesses a form item that has a label associated with
it, it will read the label and indicate the type of form item it is (e.g., "First Name. Text box" or "Age.
Check box"). Labels are needed for all form elements, except for buttons - the screen reader reads the
text that is on the button (e.g., "Submit button").
2.3.2 Group related form elements using the <fieldset> tag
When you have several associated form elements, they can be grouped together by something called
a fieldset. Each fieldset should have a legend. The legend is the text that describes the associated group
of form items. In the above example, fieldsets are defined for Computer Type and Internet Speed. In
Internet Explorer and Netscape 6 you can see the fieldset as a box around them (Netscape 4.x does not
support the fieldset tag).
The fieldset is defined by the border that surrounds the three checkboxes and their adjacent labels.
The legends of the fieldsets are the words Computer Type and Internet Speed. In this example, the label
for the first checkbox in the Internet Speed fieldset is 0-20. The fieldset is important, because without it,
if the screen reader were to access the checkbox, it would read something like, "Twenty eight point eight.
Not checked". While this is valuable, it gives no description of what the data is for. Is 28.8 referring to
Internet speed, age, height, IQ, or something else. With the fieldset in place, the screen reader would read
something like, "Internet speed: Twenty eight point eight. Not checked." Fieldsets should be used when
there are groups of check boxes or radio buttons. They can also be used for other form items that are
associated.
Even if the screen reader is incapable of reading the label, fieldset, and legend tags that were added
above (as is the case with some older screen readers), the improved table above is organized in such a
way as to make it possible to figure out which labels go with which controls. At the time of this writing,
IBM Home Page Reader was the most complete in its support of form accessibility features. JAWS
supported the label tag, but did not read the legend tag when navigating through a form with the tab key,
although JAWS did read the information when the tab key was not being used. Perhaps the next version
of JAWS will have more complete support for form elements.
Let's hear what the form sounds like now, with the improvements that we made:
Home Page Reader, reading the form straight through. Choose a format: WAV | MP3 | RealAudio |
Read Transcript
Home Page Reader, using the tab key. Choose a format: WAV | MP3 | RealAudio | Read
Transcript
To get a better idea of what went on behind the scenes, let's take a look at the HTML.

3 de 3 31/01/2005 11:06 p.m.

www.webaim.org

Part 3: Associating Labels with Form Elements
3.1 Sample Code
Here is the HTML markup for the previous form. Notice the label, id, fieldset, and legend tags. On
the next page, you will see how each type of form control can be made accessible.
[skip over code]
<form method="post" action="">

<table width="50%" border="0" cellspacing="0" cellpadding="4">
<tr bgcolor="#CCCCCC">
<td>
<p align="right"><label for="fname">First Name</label></p>
</td>
<td>
<input id="fname" type="text" name="text33" size="12">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="lname">Last Name</label></p>
</td>
<td>
<input id="lname" type="text" name="text34" size="12">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="mi">Middle Initial</label></p>
</td> <td> <input id="mi" type="text" name="text35" size="1">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="hphone">Home Phone</label></p>
</td>
<td>
<input id="hphone" type="text" name="text36" size="12">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="wphone">Work Phone</label></p> </td>
<td>
<input id="wphone" type="text" name="text37" size="12">
</td>
1 de 2 31/01/2005 11:07 p.m.

</tr>
<tr bgcolor="#FFCCFF">
<td>
<p align="right"><label for="country">Country</label></p>
</td>
<td>
<input id="country" type="text" name="text38" size="12">
</td>
</tr>
<tr bgcolor="#CCCCFF">
<td>
<fieldset>
<legend>Computer Type</legend> <br>
<input id="mac" type="radio" name="radiobutton3"
value="radiobutton">
<label for="mac">Mac </label><br>
<input id="pc" type="radio" name="radiobutton3"
<label for="pc">PC</label><br>
<input id="linux" type="radio" name="radiobutton3"
<label for="linux">Linux</label><br>
</fieldset></td>
<td>
<fieldset>
<legend>Internet Speed </legend> <br>
<input id="speed288" type="radio" name="radiobutton4"
<label for="speed288"> 28.8 </label><br>
<input id="speed56k" type="radio" name="radiobutton4"
<label for="speed56k">56k </label><br>
<input id="speedt1" type="radio" name="radiobutton4"
<label for="speedt1">T1</label>
</fieldset></td>
</tr>
</table>
</form>
Let's now look at specific form elements with accessibility features added.

2 de 2 31/01/2005 11:07 p.m.

www.webaim.org

Part 4: Accessible Form Controls
Part 4 Contents
Input
Textarea
Checkboxes
Radio Buttons
Select
Button
Image Button
JavaScript jump menus
Here are example form controls with accessibility features added:
4.1 Control type: INPUT

Name
Here's the HTML markup:
<label for="name">Name</label>
<input id="name" type="text" name="textfield">
4.2 Control type: TEXTAREA

Explain your motives:
1 de 4 31/01/2005 11:07 p.m.

<label for="motives">Explain your motives:</label><br>

<textarea id="motives" name="textfield2"></textarea>?
4.3 Control type: CHECKBOXES

Choose a color:
g Blue
c
d
e
f
c Green
d
e
f
g
c Yellow
d
e
f
g

<fieldset>
<legend>Choose a color:</legend><br>
<input id="blue" type="checkbox" name="checkbox"
value="checkbox">
<label for="blue">Blue</label><br>
<input id="green" type="checkbox" name="checkbox2"
value="checkbox">
<label for="green">Green</label><br>
<input id="yellow" type="checkbox" name="checkbox3"
value="checkbox">
<label for="yellow">Yellow</label>
</fieldset>
4.4 Control type: RADIO BUTTONS

Choose a car:
j Chrysler
k
l
m
n PT Cruiser
j Dodge
k
l
m
n Stratus
j Ford Pinto
k
l
m
n

<fieldset>
<legend>Choose a car:</legend><br>
<input id="pt" type="radio" name="radio" value="ptcruiser">
<label for="pt">Chrysler PT Cruiser</label><br>
<input id="stratus" type="radio" name="radio" value="stratus">
<label for="stratus">Dodge Stratus</label><br>
<input id="pinto" type="radio" name="radio" value="pinto">
<label for="pinto">Ford Pinto</label>
</fieldset>
4.5 Control type: SELECT

Which is your favorite city? Amsterdam 6
<label for="favcity">Which is your favorite city?</label>
<select id="favcity" name="favcity">
<option value="1">Amsterdam</option>
2 de 4 31/01/2005 11:07 p.m.

<option value="3">Interlaken</option>
<option value="4">Moscow</option>
<option value="5">Dresden</option>
<option value="2">New York</option>
<option value="6">Salt Lake City</option>
<option value="7">Logan</option>
<option value="8">Buenos Aires</option>
<option value="9">Asuncion</option>
<option value="10">Hong Kong</option>
<option value="11">Tokyo</option>
<option value="12">New Dehli</option>
</select>
To improve the accessibility of this list even further, we could add OPTGROUP tags, to group the
information. Note that the optgroup tag is not widely supported by screen readers. Window Eyes, for
example, does not yet support this tag. JAWS supports it, but only in virtual PC mode, not in forms
mode.
Which is your favorite city? Amsterdam 6
<label for="favcity2">Which is your favorite city?</label>
<select id="favcity2" name="favcity2">
<optgroup label="Europe">
<option value="1">Amsterdam</option>
<option value="3">Interlaken</option>
<option value="4">Moscow</option>
<option value="5">Dresden</option>
</optgroup>
<optgroup label="North America">
<option value="2">New York</option>
<option value="6">Salt Lake City</option>
<option value="7">Montreal</option>
</optgroup>
<optgroup label="South America">
<option value="8">Buenos Aires</option>
<option value="9">Asuncion</option>
</optgroup>
<optgroup label="Asia">
<option value="10">Hong Kong</option>
<option value="11">Tokyo</option>
<option value="12">New Dehli</option>
</optgroup>
</select>
4.6 Control Type: BUTTON

There are no special HTML tags for buttons. They are accessible as long as you use a standard
button.
Submit Reset
<input type="submit" name="Submit" value="Submit">
<input type="reset" name="Submit2" value="Reset">
4.7 Control Type: IMAGE BUTTON
3 de 4 31/01/2005 11:07 p.m.

If you use a graphic rather than a standard button, you must include an appropriate alt tag.

<input type="image" alt="submit!" border="0" name="imageField"
src="graphics/submit.gif" width="109" height="41">
4.8 Control Type: JAVASCRIPT JUMP MENUS

These menus are NOT considered keyboard accessible, because you cannot scroll through the
list without selecting one of the options. It would be better to provide a submit button separate from the
list of choices.
Select a web site 6

4 de 4 31/01/2005 11:07 p.m.

www.webaim.org

Part 5: Using Dreamweaver & FrontPage
Part 5 Contents
Using Dreamweaver to Create Accessible Forms
Using FrontPage to Create Accessible Forms
5.1 Using Dreamweaver to Create Accessible Forms

Dreamweaver 4 does not have functionality to add
additional accessibility features to forms. Form labels,
fieldgroups, and labels must all be done within the code.
It even has a menu function that allows you to add a
JavaScript driven, inaccessible jump menu, which uses a
drop-down menu item for navigation. While
Dreamweaver MX still provides an option for adding the
inaccessible jump menu, it does allow you to apply all of
the other accessibility features for forms. Use the Insert
> Fieldset menu to insert a fieldset. Dreamweaver MX
will prompt you for the fieldset legend. When
accessibility features have been turned on for forms in the
Preferences (Edit > Preferences > Accessibility >
Forms), Dreamweaver MX will prompt you for a form
label for each form item you add (Insert > Form
Object). You can also choose whether to place the label before the form item or after the form item.
Dreamweaver MX allows you to choose between the two methods of using the label tag to associate the
label with the form item.
If the form is already created, you can easily associate the labels with form items. Just highlight the
form item and its adjacent label then select Insert > Form Object > Label. Dreamweaver MX will
automatically associate the label and the form item by inserting the correct <label> tag. To add labels
to other places within the page, select Insert > Form > Label and Dreamweaver MX will insert the
<label> tag, though you must manually associate the label with a form item. This and other more
advanced accessibility techniques must be accomplished within the Code View window of
Dreamweaver.
5.2 Using FrontPage to Create Accessible Forms

Microsoft FrontPage also supports the form label functionality. To associate labels and form items,
first create your form and get it working and laid out the way you want it. Be sure to place the text labels
adjacent to the form item it is to be associated with. Select both the label and the form item and select
Insert > Form > Label. FrontPage does not currently allow you to add fieldset or its accompanying
legends. Form labels are only supported if they are adjacent to the form item. More advanced
accessibility techniques for forms must be accomplished in HTML view.
1 de 2 31/01/2005 11:07 p.m.


2 de 2 31/01/2005 11:07 p.m.

Creating accessible frames file:///d:/Microsoft/Creating%20accessible%20frames.htm
www.webaim.org
Creating Accessible Frames

Contents
Introduction
Frame accessibility
1.1 Introduction
Provide meaningful titles for frames which describe the frame's purpose.
Provide meaningful <noframes> content.
A frameset is a Web page which defines a collection of at least two other separate Web pages,
which are combined in the same visual space. Visual users usually experience framesets as a cohesive
entity. They can scan the contents of multiple pages all at once.
Those using screen readers cannot quickly scan the contents of multiple pages. All of the content is
experienced in a linear fashion, one frame at a time. Frames are not inaccessible to modern screen
readers, but they can be disorienting.
The screen reader JAWS usually reads all of the frames in a frameset, almost as if they belong to the
same page. The user is alerted that a frameset is present, then continues to read all of the pages in the
frameset. There is a keyboard shortcut which allows the reader to jump quickly between frames.
Other programs handle frames differently. Home Page Reader does not automatically read the pages
in the frameset. Instead, it presents the user with a list of frames within the frameset and allows the user
to choose which frame to go to first.
1.2 Frame Accessibility

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
<HEAD>
<TITLE>A page that contains frames</TITLE>
</HEAD>
<FRAMESET cols="15%, 85%">
<FRAME src="menu.html" title="Navigation menu" name="menu">
<FRAME src="content1.html" title="Main content" name="content">
<NOFRAMES> <P>This frameset document contains:
<UL> <LI><A href="menu.html">Page navigation</A></LI>
<LI><A href="content1.html">Main content</A></LI> </UL>
</NOFRAMES>
</FRAMESET>
</HTML>
1 de 2 31/01/2005 11:06 p.m.

Creating accessible frames file:///d:/Microsoft/Creating%20accessible%20frames.htm
One of the most important things you can do to increase the accessibility of frames is to give each
frame a title.
When a screen reader user hears a list of frames, it is helpful to know the purpose of each
one. Frame titles allow web developers to communicate the purpose of each frame to users
of screen readers.
When frame titles are not present, screen readers look for other sources of information, such
as the frame's "name" attribute or file name. Sometimes these other sources of information
are not very helpful at all. If a frame is given a name or filename of "default3" (or something
equally nondescript), there is really no way to know what the frame contains, other than by
trial and error.
The best titles for frames are brief and descriptive. Appropriate titles for the frames in a
two-frame frameset might be "navigational frame" and "main content."
A page that uses frames should have the correct document type. The code example above shows a
DOCTYPE for a frameset page that uses HTML 4.
NOFRAMES content should always be available if the user cannot or chooses not to view frame
content. The noframes content should indicate what the contents of the frames are and provide
links to individual frame pages if appropriate.

2 de 2 31/01/2005 11:06 p.m.

Semantic Structure file:///d:/Microsoft/Semantic%20Structure.htm
www.webaim.org
Semantic structure
Contents
Using Content Structure Correctly
The nature of HTML
Using headings for content structure
Using headings correctly
Using lists correctly
Sighted people are able to quickly scan over an entire Web page. They can visually skip past the
advertisements, past the main navigation and go directly to the main content. They can ignore the
extraneous information all around the main content, without ever having to pay attention to it. Those who
use screen readers experience Web sites a little differently. They are not able to immediately zero in on
the main content of a Web page. They must find it by listening to the advertisements and the main
navigation system. They can speed up the process by tabbing from link to link, but they risk missing an
important piece of information this way. The experience is definitely different.
One thing that could enhance the experience for those who use screen readers would be the ability
to listen to an outline of a Web page before going to any specific area. This would give them a similar
experience to that of sighted people who skim over the Web page. As it turns out, screen readers have
this capability. They allow the user to navigate from heading to heading, through the hierarchical
organization of content. The problem is that this structure has to be in place to begin with. If developers
don't include headings in their markup, screen reader users cannot skim through the outline of Web
pages.
Key concepts
HTML is a structure language, not a display language.
HTML standards demand proper content structure.
Properly structured content is more accessible.
Use content structure HTML to mark up structure and not for appearance.
Using Content Structure Correctly

The nature of HTML
The originators of HTML were scientists who wanted a standard means to share particle physics
documents. They had little interest in the exact visual form of the document as seen on the computer
screen. In fact, HTML was originally designed to enforce a clean separation of content structure and
graphic design. The intent was to create a World Wide Web of pages that will display in every system
and browser available, including browsers that "read" Web page text to visually impaired users and can
be accurately interpreted by automated search and analysis engines.
The inventors of the Web did not realize the graphical and display potential of the Web, and as such,
1 de 3 31/01/2005 11:11 p.m.

HTML was not designed with display considerations in mind. They were so concerned about making
Web documents machine-friendly that they produced documents that only machines (or particle
physicists) would want to read. In focusing solely on the structural logic of documents they ignored the
need for the visual logic of graphic design and typography. This lack of a visual emphasis on the Web is
what causes Web designers such stress in trying to get pages to look the way that they want them to look.
This pressure is what caused browser software companies to begin to ignore the standards of proper
HTML and allow additional visual and layout features or extensions of HTML work within their
browsers.
For example, most graphic designers avoid using the standard heading tags in HTML (H1, H2, and
so on) because they lack subtlety: in most Web browsers these tags make headlines look absurdly large
(H1, H2) or ridiculously small (H4, H5, H6). But the header tags in HTML were not created with graphic
design in mind. Their sole purpose is to designate a hierarchy of headline importance, so that both human
readers and automated search engines can look at a document and easily determine its information
structure. Only incidentally did browser designers create a visual hierarchy for HTML headers by
assigning different type sizes and levels of boldness to each header element, though these type sizes tend
to be somewhat limiting within the HTML language.
Using headings for content structure
Despite the nature of the Web and the vast change in it's role from a structural medium to a visual
media, it is still important that Web content be designed with proper structure. With better support for
cascading style sheets in recent versions of Web browsers, developers can change the appearance of
structural elements to meet their design and visual preferences.
View the content structure of one of your Web pages by accessing

http://validator.w3.org/detailed.html. Enter the Web page URL into the text box, check the 'Show
Outline' checkbox, and press 'Validate this page'. For now, ignore any HTML errors that are shown and
scroll to the bottom of the page to see the page's outline. You will see a brief outline of the content
structure of your Web page as defined by headers tags (H1 - H6). If the output does not look like a real
outline, it is likely that the heading tags are not being used properly (or that there are aren't any heading
tags).
Screen reader and other assistive technology users have the ability to navigate Web pages by
structure. This means that the user can read or jump directly to top level elements (H1), next level
elements (H2), third level elements (H3), and so on. Viewing or listening to this outline should give them
a good idea of the contents and structure of the page. Pages should be structured in a hierarchical manner,
with 1st degree headings (H1) being the most important (usually page titles or heading), then 2nd degree
headings (H2 - usually major section headings), down to 3rd degree headings (sub-sections of the H2),
and so on. Technically, lower degree headings should be contained within headings of the next highest
degree. The following outline shows the hierarchy of what a Web page might contain. In fact, it
represents the hierarchy of the main content section of this page, with different degrees of headers to
represent higher or lower levels of content hierarchy. You can click on any of the heading items to jump
to that section within this page.
Heading 1
Heading 2
Heading 2
Heading 2
Heading 3
Heading 3
Heading 4
2 de 3 31/01/2005 11:11 p.m.

Heading 3
Heading 3
Using headings correctly
Do not use text formatting, such as font size or bold to give the visual appearance of headings -
use actual heading (H1 - H6) for all content headings. Assistive technologies and other browsers rely
upon the literal markup of the page to determine structure. Items that are bolded or display in a bigger
font are not interpreted to be structural elements.
Likewise, do not use headers to achieve visual results only. For instance, if you want to highlight
or emphasize an element within your content that is not a heading (such as was done in the previous
sentence), do not use heading tags to achieve the visual appearance you want. Instead, use font size, bold,
or italics. Actually, you should use styles to achieve visual results. If you want to emphasize something,
you technically should use the <strong> tag instead of <bold> and the <em> tag instead of <i>. Bold and
italics (<i>) both connote visual emphasis, whereas strong and emphasis (<em>) suggest semantic
emphasis. Visually, <b> and <strong>, and <em> and <i> look exactly the same, but developers should
use the more proper html tags. In Dreamweaver, you can select Edit > Preferences > General and select
Use <strong> and <em> in place of <b> and <i>.
Using lists correctly
HTML lists - <ul>, <ol>, and <dl> - also convey a hierarchical content structure. Each of these have
rules regarding their use as well. Unordered lists should be used when there is no order of sequence or
importance. Ordered lists suggest a progression or sequence. Definition lists should be used explicitly for
presenting a structure for definitions. As with heading, lists should be used correctly and for the right
purposes. Unordered and ordered lists should always contain list items. Definition lists must always have
definition descriptions. Empty lists are incorrect HTML. Lists should never be used for merely indenting
or other layout purposes. Nested lists should be coded properly.

3 de 3 31/01/2005 11:11 p.m.

Tutorial FrontPage 2003

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tutorial FrontPage 2003

Uploaded by

Copyright:

Available Formats

www.webaim.

Using FrontPage 2003 to Create Accessible

Just like every tool, FrontPage does have its weaknesses:

New Accessibility Features in FrontPage 2003

Improved XHTML support

Creating Accessible Content

Change the default template to one that is valid

Add a DOCTYPE declaration using shortcuts

Change the default template

Create multiple templates

Keyword: This should be a one word description of the snippet.

4 de 9 31/01/2005 10:57 p.m.

Adding alt attributes to images

Creating accessible client-side image maps

To create an accessible client-side image map, follow these steps:

Insert the image into your Web page.

Defining table headers

Adding labels to form elements

Create your form using the Insert > Form menu.

Giving titles to frames

Note: This feature is new to FrontPage 2003.

There are two different ways to add titles to your frames.

7 de 9 31/01/2005 10:57 p.m.

Using FrontPage 2000 to Create Accessible Content

Related external sites:

Building Accessible Web Sites with FrontPage 2003

Copyright (c) 1998-2005 WebAIM (www.webaim.org). All rights reserved.

Creating Accessible Images

1 de 3 31/01/2005 10:58 p.m.

2 de 3 31/01/2005 10:58 p.m.

Copyright (c) 1998-2005 WebAIM (www.webaim.org). All rights reserved.

3 de 3 31/01/2005 10:58 p.m.

Creating Accessible Images

make your font sizes as large as possible

1 de 2 31/01/2005 10:58 p.m.

Copyright (c) 1998-2005 WebAIM (www.webaim.org). All rights reserved.

2 de 2 31/01/2005 10:58 p.m.

Creating Accessible Images

4.1 Flicker and Strobe

4.2 How Can You Know If Your Graphics Will Cause a

Copyright (c) 1998-2005 WebAIM (www.webaim.org). All rights reserved.

1 de 1 31/01/2005 10:58 p.m.

Creating Accessible Images

Guidelines for alt text:

5.2 The Importance of Alternative Text

1 de 8 31/01/2005 10:58 p.m.

Experience it for yourself

Experience it for yourself

5.3 Adding Alt Text

2 de 8 31/01/2005 10:58 p.m.

The HTML code for this image is as follows:

3 de 8 31/01/2005 10:58 p.m.

5.4 How Images Are Used

1. to convey important content

5.5 Communicating the Purpose of the Graphic

Take another look at the portrait of Silvia below:

4 de 8 31/01/2005 10:58 p.m.

5.5.1.1 Accuracy and brevity

5.5.2 Null alt text

5 de 8 31/01/2005 10:58 p.m.

5.5.2.1 Decorative images

5.5.2.2 Transparent and spacer images

5.5.2.3 Redundant images