Dreamweaver Accessibility Document

This document is also available here as a PDF.

Table of Contents

  1. About This Document
  2. Dreamweaver Settings & Techniques
    • Setting Dreamweaver Accessibility Preferences
    • General Coding Techniques
  3. Priority 1 Checkpoints
    1. Checkpoint 1
    2. Checkpoint 2
    3. Checkpoint 3
    4. Checkpoint 4
    5. Checkpoint 5
    6. Checkpoint 6
    7. Checkpoint 7
    8. Checkpoint 8
    9. Checkpoint 9
    10. Checkpoint 10
    11. Checkpoint 11
    12. Checkpoint 12
    13. Checkpoint 13
    14. Checkpoint 14
    15. Checkpoint 15
    16. Checkpoint 16
    17. Checkpoint 17
    18. Checkpoint 18
  4. Resources
  5. Why is Web Accessibility Important?
  6. Who Does it Benefit?
  7. Who Else Does it Benefit?
  8. What Do I Need to Do? Priority 1 Checklist
  9. What Do I Need to Do? Priority 2 Checklist
  10. What Do I Need to Do? Priority 3 Checklist

About This Document

This document focuses on using Dreamweaver to author accessible web sites, and is a compilation of original material and information from several publicly available web sites. Web sources are identified at the beginning of any section in which they are used.

Dreamweaver Settings & Techniques

SETTING DREAMWEAVER ACCESSIBILITY PREFERENCES

There are several preferences that you can set in Dreamweaver to help you build accessible web sites. Before you start, check the following categories in Dreamweaver preferences, and ensure that the following items are enabled:

example of Preferences dialogue box

GENERAL CODING TECHNIQUES

Priority 1 Checkpoints

CHECKPOINT 1

Text equivalent is provided for every non-text element (e.g., via "alt", or "longdesc"). This includes: images, graphical representations of text (including symbols), image map regions, animations, applets & programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds, stand-alone audio files, audio tracks of video, and video.

If you have turned on the Accessibility options in Dreamweaver’s Preferences, whenever you insert an image Dreamweaver will prompt you to enter alt text and/or a link to the longdesc for the image.

example of alternate text box

Alt text should be a short (i.e. less than 1 sentence) description of the image. One example is “Courseware Development Center Logo”. A second example (see screenshot above) is “Fish Xing CD Cover”.

Alt text can also be entered by selecting the image or hotspot and then typing into the Alt box in the Properties window (see screenshot).

Note: if an image is used as a graphic device and does not add meaning to the document, enter a space as the alt tag. If you don’t, when a screen reader gets to this image it will say the word “Image”. The html should look like this: <img src="../images/line.gif" width="4" height="127" alt=" " />

Longdesc is used when the object can’t be described with a single sentence. It is usually used to provide text equivalents to animations, detailed photos, video, audio, etc., as well as within <frame> tags as a description of the frame contents. The longdesc is a link to a plain html file (text-only) that describes the object in detail. The code for an image with a longdesc attribute will look like this: <img src="images/alt.jpg" width="358" height="244" longdesc="descriptions/alt.html" />.

CHECKPOINT 2

A method is provided that permits users to skip repetitive navigation links.

Implementation Method (from w3c.org)

Immediately prior to the first link in the navigation, include a transparent image sized to one pixel square with a border value of zero and an alt text value similar to "jump to content" or "skip navigation".

Immediately prior to the first word in the content area of a page insert a named anchor (Insert > Named Anchor) with a name value of “content”.
Create a link from the one pixel square transparent image to the named anchor.

This technique will allow the end-user utilizing adaptive technology to jump to the page content, thereby ignoring the repetitive navigation links just as a sighted end-user would.

CHECKPOINT 3

All information conveyed with color is also available without color, (e.g., from context or markup).

Colors on a page should be used for decoration or to enhance graphics. They should not be used to convey information. This point must be assessed visually.

How to Check (from w3c.org)

Make sure the page can be understood and navigated regardless of color scheme. To test the page:

Discussion

Although the web is an extremely visual environment, there are many situations where an end-user may not be able to see the colors. These include:

CHECKPOINT 4

Changes in the language of a document's text and any text equivalents are clearly specified. (from w3c.org)

If you use a number of different languages on a page, make sure that any changes in language are clearly identified by using the "lang" attribute. The easiest way to add the lang attribute is to type it in to the source view of your page in Dreamweaver.

Example:

<p>And with a certain <span lang="fr">je ne sais quoi</span>, she entered both the room, and his life, forever. <q>My name is Natasha,</q> she said. <q lang="it">Piacere,</q> he replied in impeccable Italian, locking the door.</p>

Identifying changes in language are important for a number of reasons:

CHECKPOINT 5

Document is readable when rendered without associated style sheets.

Make sure that your content makes sense with stylesheets turned off. The easiest way to do this is to temporarily change or remove the link to your stylesheets, and view your site in a browser. There are also several favlets online that can be used to turn off the stylesheets of any web page your browse to.

This point is important because:

CHECKPOINT 6

Text equivalents for dynamic content are present and updated when the dynamic content changes.
Multimedia (from w3c.org)

If <object> tags are used, provide a text equivalent in the content of the element. This is most easily done by typing into the code view in Dreamweaver. Text between the <object> tags will not show in browsers, but will be read by assistive technologies.

<object classid="java:Press.class" width="500" height="500"> As temperature increases, the molecules in the balloon...</object>

Scripts:

When using <script>, always follow with a <noscript> element. The content of this element is rendered when scripts are not enabled. This will also need to by typed into Dreamweaver’s code view.

<SCRIPT type="text/tcl"> ...some Tcl script to show a billboard of sports scores...</SCRIPT>
<NOSCRIPT> <P>Results from yesterday's games:</P>
<DL>
<DT>Bulls 91, Sonics 80.
<DD><A href="bullsonic.html">Bulls vs. Sonics game highlights</A> ...more scores... </DL> </NOSCRIPT>

CHECKPOINT 7

The page avoids causing the screen to flicker.

This is accomplished by making good design decisions. Don’t use <blink> tags, don’t automatically refresh the page contents, don’t include flickering effects in animations, and don’t write scripts that cause blinking or flickering, or that turn contents on and off repeatedly.

CHECKPOINT 8

Site uses the clearest and simplest language appropriate for the content.

For the most part, this is the responsibility of the content provider. Some points to consider:

CHECKPOINT 9

Redundant text links for each active region of a server-side image map are provided.

The image maps made by Dreamweaver are client-side, so if you building a static site in Dreamweaver you won’t have to worry about this.

CHECKPOINT 10

Client-side image maps are provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

As stated in #9, Dreamweaver only makes client-side image maps. Don’t forget to include alt text for each hotspot in your image maps if you use them.

CHECKPOINT 11

Row and column headers are identified for all data tables.

Screen Readers and Tables: (from Macromedia.com)

Before creating accessible tables, it's important to understand how screen readers interact with tables. First of all, tables are generally used in one of two ways: to control the layout of a page and to present data.

Using tables for page layout is an easy way to create columns, align elements on a page, or control page width. Earlier versions of screen readers had great difficulty handling tables of any kind, so designers were discouraged from using tables for layout. The latest generation of screen readers now works more effectively with tables. In general, current versions read tables row by row, from left to right. As long as the contents of the page make sense when read across, you can use tables for page layout.

Tables used to present data are read the same way. The screen reader will read the top row from left to right, and continue reading across each of the following rows. One problem with the current method is the difficulties screen reader users may have in remembering column headings during the reading, as the following example illustrates:

example of data in a table

A screen reader would likely read this table as follows:

“Online Training Courses. Course Name. Instructor. Summary. Code. Introduction to the WWW. Hannah Marsh. This course will provide an overview of using the World Wide Web. mw103. Cascading Style Sheets. Luis Gandin. This course provides an introduction to text formatting using CSS. mw105. Flash MX. Alan Foley. This course provides an introduction to application development using Flash MX. mw203. ActionScript. Lexie Frances. This course reviews the advanced techniques for scripting in Flash MX.. mw303.”

Without the column headers to help keep track of the purpose of each piece of information, it's difficult to make sense of the table. To help organize the information, screen readers often have a table-reading mode. In this mode, the column or row headers (if they are properly marked up) may be read before each piece of data. Using the table-reading mode, the first two rows of the same table might be read as follows:

“Online Training Courses. Course Name. Introduction to the WWW. Instructor. Hannah Marsh. Summary. This course will provide an overview of using the World Wide Web. Code. mw103. Course Name. Cascading Style Sheets. Instructor. Luis Gandin. Summary. This course provides an introduction to text formatting using CSS. Code. mw105.”

It's much easier to grasp and keep track of information presented in this mode, with the header read before each piece of information. In addition, screen reader users may also read a table summary, which provides a quick overview of the table to help orient users to the information presented.

Adding Captions and Summaries

After the Accessibility preferences have been set (see preferences), the dialog box shown below appears when you insert a table on the page:

example of accessible table settings

The first six options in this dialog box remain constant when the Accessibility preferences are not activated: Rows, Columns, Cell Padding, Width, and Border. For more detailed information about these properties, see Setting Table Properties in Dreamweaver MX Help.

Enter a table title in the Caption text box. The title (caption) should be brief and describe the information contained in the table. The caption will be displayed as a table title by default. You can use the Align Caption option to align the caption to the left or right, or to place it at the bottom of the table.

The Summary text box allows you to describe the data presented in the table. This description should give users a general understanding of the information without data-specific details. Summary text will not be visible on the page.

Specifying Headers

The use of headers in a table helps organize the information read by screen readers. The Header option shown in the preceding dialog box enables you to quickly and easily specify headers and link the table data to those headers. However, this feature will only work with relatively simple tables (one or two levels of headings). More complex tables (three or more levels of headings) require a more complex HTML mark-up than is represented here.

The Heading text box offers four choices. The first selection, None, specifies no headers. The second Heading selection, Column, allows you to change the first column to a single column of headers. An example of a table with a single column of headers is shown below.

example of table with single column of headers


The third Heading selection allows you to change the table's first row to a single row of headers. You can see an example of this selection at the beginning of this document. The final Heading selection lets you change both the first row and first column of the table into headers. Below is an example of a table with row-and-column headers.

example of a table with row and column headers

CHECKPOINT 12

Markup associates data cells with header cells in data tables that have two or more logical levels of row or column headers.

When tables are too complicated to use the Dreamweaver tools described above, you will have to do some hand coding. The following examples, from w3c.org, describe 3 possible ways to address complicated data tables.

In General

Example 1

This example shows how to associate data cells (created with TD) with their corresponding headers by means of the "headers" attribute. The "headers" attribute specifies a list of header cells (row and column labels) associated with the current data cell. This requires each header cell to have an "id" attribute.

<TABLE border="1" summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.">
<CAPTION>Cups of coffee consumed by each senator</CAPTION>
<TR>
<TH id="header1">Name</TH>
<TH id="header2">Cups</TH>
<TH id="header3" abbr="Type">Type of Coffee </TH>
<TH id="header4">Sugar?</TH>
<TR>
<TD headers="header1">T. Sexton</TD>
<TD headers="header2">10</TD>
<TD headers="header3">Espresso</TD>
<TD headers="header4">No</TD>
<TR>
<TD headers="header1">J. Dinnen</TD>
<TD headers="header2">5</TD>
<TD headers="header3">Decaf</TD>
<TD headers="header4">Yes</TD>
</TABLE>

A speech synthesizer might render this tables as follows:

“Caption: Cups of coffee consumed by each senator. Summary: This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar. Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes”

A visual user agent might render this table as follows:
example of table made with header attributes

Example 2

This example associates the same header (TH) and data (TD) cells as before, but this time uses the "scope" attribute rather than "headers". "Scope" must have one of the following values: "row", "col", "rowgroup", or "colgroup." Scope specifies the set of data cells to be associated with the current header cell. This method is particularly useful for simple tables. It should be noted that the spoken rendering of this table would be identical to that of the previous example. A choice between the "headers" and "scope" attributes is dependent on the complexity of the table. It does not affect the output so long as the relationships between header and data cells are made clear in the markup.

<TABLE border="1" summary="This table charts ...">
<CAPTION>Cups of coffee consumed by each senator </CAPTION>
<TR>
<TH scope="col">Name</TH>
<TH scope="col">Cups</TH>
<TH scope="col" abbr="Type">Type of Coffee </TH>
<TH scope="col">Sugar?</TH>
<TR>
<TD>T. Sexton</TD>
<TD>10</TD>
<TD>Espresso</TD>
<TD>No</TD>
<TR>
<TD>J. Dinnen</TD>
<TD>5</TD>
<TD>Decaf</TD>
<TD>Yes</TD>
</TABLE>

Example 3

The following example shows how to create categories within a table using the "axis" attribute.

<TABLE border="1">
<CAPTION>Travel Expense Report</CAPTION>
<TR>
<TH></TH>
<TH id="header2" axis="expenses">Meals
<TH id="header3" axis="expenses">Hotels
<TH id="header4" axis="expenses">Transport
<TD>subtotals</TD>
<TR>
<TH id="header6" axis="location">San Jose
<TH> <TH> <TH> <TD>
<TR>
<TD id="header7" axis="date">25-Aug-97
<TD headers="header6 header7 header2">37.74
<TD headers="header6 header7 header3">112.00
<TD headers="header6 header7 header4">45.00
<TD>
<TR>
<TD id="header8" axis="date">26-Aug-97
<TD headers="header6 header8 header2">27.28
<TD headers="header6 header8 header3">112.00
<TD headers="header6 header8 header4">45.00
<TD>
<TR>
<TD>subtotals
<TD>65.02
<TD>224.00
<TD>90.00
<TD>379.02
<TR>
<TH id="header10" axis="location">Seattle
<TH> <TH> <TH> <TD>
<TR>
<TD id="header11" axis="date">27-Aug-97
<TD headers="header10 header11 header2">96.25
<TD headers="header10 header11 header3">109.00
<TD headers="header10 header11 header4">36.00
<TD>
<TR>
<TD id="header12" axis="date">28-Aug-97
<TD headers="header10 header12 header2">35.00
<TD headers="header10 header12 header3">109.00
<TD headers="header10 header12 header4">36.00
<TD>
<TR>
<TD>subtotals
<TD>131.25
<TD>218.00
<TD>72.00
<TD>421.25
<TR>
<TH>Totals
<TD>196.27
<TD>442.00
<TD>162.00
<TD>800.27
</TABLE>

This table lists travel expenses at two locations: San Jose and Seattle, by date, and category (meals, hotels, and transport). The following image shows how a visual user agent might render it.

example of table created with "axis" attribute

CHECKPOINT 13

Each frame is titled to facilitate frame identification and navigation.

If you have turned on the accessibility options (see preferences), when you create a frameset in Dreamweaver MX, the accessibility dialog will open and prompt you to enter a title for each frame in the frameset. The title should refer directly to the content of the frame, such as “Navigation”, or “Main Content”. A text description of the frameset should also be provided using the longdesc attribute, or between <noframe> tags. Contents in <noframe> tags are not shown in graphical browsers.

example of frame title dialogue box

CHECKPOINT 14

Forms allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

If you have set Dreamweaver’s Accessibility preferences are set, you will be prompted to provide relevant accessibility information when you create forms. As you add each text box, you'll be asked to provide a label, the tab index, and an access key. All of this prompted information makes the form significantly easier to navigate for people with disabilities. In the following example (from Marcomedia.com), you'll see how to create a simple training registration form.

Adding Labels

Labels identify the purpose of individual form objects, such as a text box, check box, or Submit button. When working with forms, users usually assume that the text to the left of the form object identifies its purpose. In many cases, this is true; however, sometimes the visual layout requires labels to be located to the right, above, or even below the form object. This can lead to considerable confusion for assistive technology users.

Labels associate the label text with the form object through HTML. If the labels are identified in the HTML, a screen reader will read the text label identified with the form object, regardless of where the label is placed visually. While it's also important to pay attention to the visual layout of labels, identifying labels within the HTML can make pages much easier for people to use with screen readers and other assistive technologies.

When a form object is inserted on a page in Dreamweaver MX, the following dialog box appears:

example of label dialogue box

In this example, a simple text box needs to be added. The text label "First Name" is entered in the Label text box.

Below the Label text box are three Style options. The first two allow you to specify the HTML coding technique used to mark up the label. Both represent standard HTML and will look the same on the page.

The Wrap with Label Tag option places the HTML element <label> around the label and the form object itself. This method is the simplest; however, it assumes that the label and the form object will always be next to each other. This may not always be the case for each form element.

The Attach Label Tag Using the 'for' Attribute option allows the label and form object to be separated by table cells or placed above or below each other. This option requires a bit more HTML code, but offers more flexibility than the first method.

When using the Attach Label Using 'for' Attribute option, remember that if the text label is moved, the HTML label must be moved along with it. The easiest way to accomplish this is to select the HTML label element at the bottom of the Dreamweaver MX window before dragging the text label elsewhere on the page.

example of text labelexample of HTML label

This procedure will move the underlying HTML code along with the text.

The No Label Tag option allows you to omit a label. This option is also helpful when you plan to add labels at a later time. However, Section 508 standards based on W3C guidelines require labels to be identified within the HTML.

The next set of options in this dialog box allows you to decide whether to place the label before or after the form object. You can choose either option, as long as your label placement is consistent throughout the page.

example of label dialogue box

Setting an Access Key

Access keys allow users to quickly access individual form objects using a keyboard shortcut. This is especially helpful on long forms that would otherwise require users to press the tab key numerous times to access each text box. The inclusion of access keys is not required under Section 508 standards or most policies based on W3C guidelines, but it can make a form much easier to navigate, especially for people with mobility impairments.

In the form on the left, the access key for the Label text box is set to 'T.' To use this access key, users would press Alt+T to move the cursor directly.

There are two issues to consider when adding access keys. First, you need to avoid standard key combinations used in web browsers. For example, a natural choice for the Label text box might have been Alt+F; however, Alt+F activates the File menu in most Microsoft Windows applications. Instead, the letter 'T' was chosen from the end of the word 'First.'

example of text label

Also, keep in mind that once an access key is specified, users need to be notified. The most common way to do this is to underline the letter used as the access key in the label of the form object. Note that the underlined text here is formatted using Cascading Style Sheets (CSS).

Setting a Tab Index

A tab index specifies the order in which the tab key will move among the individual page elements. In many browsers, the tab key will move among links, media objects, and form objects on the page. The default tab order is determined by the order in which these objects appear in the HTML code. If this order differs from the visual layout, a tab index might prove helpful. As with access keys, specifying a tab index is not required under Section 508 or most policies based on W3C guidelines, but it can make a page more navigable for disabled users when the layout is complex, or the default tab order is unusual.

However, once a tab order is specified, that order needs to be specified for all the form objects that precede it. For example, a form object cannot be given the tab index value of 7 without specifying objects 1 through 6. Furthermore, if the tab order is not specified beyond 7, then the browser will return to the default tab order from that point forward.

CHECKPOINT 15

Pages are usable when scripts, applets, or other objects are turned off or unsupported.

Check this by turning off or temporarily disabling scripts. The contents of the page should still make sense when the scripts don’t run.

CHECKPOINT 16

Page provides a link to any plug-in or applet that is required to be present on the client system to interpret page content, and these applets or plug-ins are accessible.

Provide links to plug-ins when embedding them into web pages according to the following example:

<OBJECT classid="clsid:A12BCD3F-GH4I-56JK-xyz" codebase="http://example.com/content.cab" width=100 height=80>
<PARAM name="Movie" value="moviename.swf">
<EMBED src="moviename.swf" width=100 height=80 pluginspage="http://example.com/shockwave/download/"> </EMBED>
<NOEMBED> <IMG alt="Still from Movie" src="moviename.gif" width=100 height=80> </NOEMBED>
</OBJECT>

Information between <noembed> tags will not display in graphical browsers. Dreamweaver will add the codebase and and pluginspage attributes automatically, but you will have to add the <noembed> tags by hand.

CHECKPOINT 17

An auditory description of the important information of the visual track is provided.

This point will need to be addressed while designing multimedia.

CHECKPOINT 18

Equivalent alternatives (e.g., captions or auditory descriptions of the visual track) are synchronized to any time-based multimedia presentation (e.g., a movie or animation).

This point will need to be addressed while designing multimedia.

 

Resources

Why is Web Accessibility Important?

Most people today can hardly conceive of life without the Internet. It provides access to information, news, email, shopping, and entertainment. The Internet, with its ability to serve out information at any hour of the day or night about practically any topic conceivable, has become a way of life for an impatient, information-hungry generation. Some have argued that no other single invention has been more revolutionary since that of Gutenberg's original printing press in the mid 1400s. Now, at the click of a mouse, the world can be "at your fingertips"--that is, if you can use a mouse . . . and if you can see the screen . . . and if you can hear the audio--in other words, if you don't have a disability of any kind.

Who Does it Benefit?

An estimated 20 percent of the population in the United States (40.8 million individuals) has some kind of disability, and 10 percent (27.3 million individuals) has a severe disability. The 27.3 million individuals with severe disabilities are limited in the way that they can use the Internet. The saddest aspect of this fact is that the know-how and the technology to overcome these limitations already exist, but they are greatly under-utilized, mostly because Web developers simply do not know enough about the issue to design pages that are accessible to people with disabilities. Unfortunately, even some of the more informed Web developers minimize the importance of the issue, or even ignore the problem altogether.

The Web can present barriers to people with different kinds of disabilities, such as the following design problems:

VISUAL DISABILITIES:

HEARING DISABILITIES:

PHYSICAL AND SPEECH DISABILITIES:

COGNITIVE OR NEUROLOGICAL DISABILITIES:

Who Else Does it Benefit?

Accessible Web design contributes to better design for other users:

MULTI-MODALITY (SUPPORT FOR VISUAL, AUDITORY, TACTILE ACCESS) BENEFITS USERS OF:

REDUNDANT TEXT/AUDIO/VIDEO CAN SUPPORT:

STYLE SHEETS CAN SUPPORT:

CAPTIONING OF AUDIO FILES SUPPORTS:

MULTI-MODALITY INCREASES USABILITY OF WEB SITES IN DIFFERENT SITUATIONS:

What Do I Need to Do? Priority 1 Checklist

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.

Priority 1 Checkpoints
In general Yes No N/A
1. Text equivalent is provided for every non-text element (e.g., via "alt", or "longdesc"). This includes: images, graphical representations of text (including symbols), image map regions, animations, applets & programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds, stand-alone audio files, audio tracks of video, and video.      
2. A method is provided that permits users to skip repetitive navigation links.      
3. All information conveyed with color is also available without color, (e.g., from context or markup).      
4. Changes in the language of a document's text and any text equivalents are clearly specified.      
5. Document is readable when rendered without associated style sheets.      
6. Text equivalents for dynamic content are present and updated when the dynamic content changes.      
7. The page avoids causing the screen to flicker.      
8. Site uses the clearest and simplest language appropriate for the content.      
Image maps Yes No N/A
9. Redundant text links for each active region of a server-side image map are provided.      
10. Client-side image maps are provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.      
Tables Yes No N/A
11. Row and column headers are identified for all data tables.      
12. Markup associates data cells with header cells in data tables that have two or more logical levels of row or column headers.      
Frames Yes No N/A
13. Each frame is titled to facilitate frame identification and navigation.      
Forms Yes No N/A
14. Forms allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.      
Applets and scripts Yes No N/A
15. Pages are usable when scripts, applets, or other objects are turned off or unsupported.      
16. Page provides a link to any plug-in or applet that is required to be present on the client system to interpret page content, and these applets or plug-ins are accessible.      
Multimedia Yes No N/A
17. An auditory description of the important information of the visual track is provided.      
18. Equivalent alternatives (e.g., captions or auditory descriptions of the visual track) are synchronized to any time-based multimedia presentation (e.g., a movie or animation).      
And if all else fails Yes No N/A
19. If, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information / functionality, and is updated as often as the inaccessible page.      

 

What Do I Need to Do? Priority 2 Checklist

A Web content developer should satisfy these checkpoints. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.

Priority 2 Checkpoints
In general Yes No N/A
20. Foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.      
21. Markup (not images) is used to convey information when an appropriate markup language exists.      
22. Documents validate to published formal grammars.      
23. Style sheets are used to control layout and presentation.      
24. Relative (not absolute) units are used in HTML attribute values and style sheet property values.      
25. Header elements are used to convey document structure, and used according to specification.      
26. Lists and list items are marked up properly.      
27. Quotations are marked up; quotation markup is not used for formatting effects such as indentation.      
28. Dynamic content is accessible, or an alternative presentation or page is provided.      
29. Content does not blink, and the page does not periodically auto-refresh.      
30. Markup is not used to redirect pages automatically. Instead, the server performs redirects.      
31. Pop-up windows are not used and the current window is not changed without informing the user.      
32. The latest versions of W3C technologies are used when available, appropriate, and supported. Deprecated features of W3C technologies are not used.      
33. Large blocks of information are divided into manageable groups where natural and appropriate.      
34. The target of each link is clearly identified.      
35. Metadata is provided to add semantic information to pages and sites.      
36. Information is provided about the general layout of a site (e.g., a site map or table of contents).      
37. Navigation mechanisms are used in a consistent manner.      
Tables Yes No N/A
38. Tables are not used for layout unless the tables make sense when linearized. Otherwise, an alternative equivalent (which may be a linearized version) is provided.      
39. If a table is used for layout, structural markup is not used for the purpose of visual formatting.      
Frames Yes No N/A
40. The purpose of frames and how they are related is described if not obvious from frame titles.      
Forms Yes No N/A
41. Labels are explicitly associated with their controls.      
Applets and scripts Yes No N/A
42. Event handlers are input device-independent.      
43. There is no movement of content in pages.      
44. Programmatic elements are directly accessible or compatible with assistive technologies.      
45. Any element that has its own interface can be operated in a device-independent manner.      

 

What Do I Need to Do? Priority 3 Checklist

A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

Priority 3 Checkpoints
In general Yes No N/A
46. The expansion of each abbreviation or acronym the document is specified where it first occurs.      
47. The primary natural language of the document is specified.      
48. A logical tab order through links, form controls, and objects has been created.      
49. Keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls are provided.      
50. Non-link, printable characters (surrounded by spaces) are included between adjacent links.      
51. Information is provided so that users may receive documents according to their preferences (e.g., language, content type, etc.)      
52. Navigation bars are provided to highlight and give access to the navigation mechanism.      
53. Related links are grouped, the groups are identified (for user agents), and a way to bypass the group is provided.      
54. Different types of searches for different skill levels and preferences are present if search functions are provided.      
55. Distinguishing information is placed at the beginning of headings, paragraphs, lists, etc.      
56. Information about document collections (i.e., documents comprising multiple pages) is provided.      
57. A means to skip over multi-line ASCII art is provided.      
58. Text is supplemented with graphic or auditory presentations where they will facilitate comprehension of the page.      
59. Presentation style is consistent across pages.      
Image maps Yes No N/A
60. Redundant text links for each active region of a client-side image map are provided.      
Tables Yes No N/A
61. Summaries for tables are provided.      
62. Abbreviations for header labels are provided.      
63. A linear text alternative (on the current page or some other) is provided for all tables that lay out text in parallel, word-wrapped columns.      
Forms Yes No N/A
64. Default, place-holding characters have been added to edit boxes and text areas.