WebSavvy: Resources

The following list of accessible authoring strategies have been assembled based on dozens of Web site accessibility evaluations. Many of the strategies are based on the Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines (WCAG 1.0), while others are based on creative solutions developed by clients themselves to address site specific access issues. These strategies are intended for Web content developers who are already familiar with HTML, and are looking for ways to make their Web sites accessible to a broader audience, whether that audience includes people with disabilities, those using older browsing technology, or those with slow Internet connections.

Web accessibility in the current context refers to the ability of people who have disabilities to access Web content. Many individuals with disabilities use assistive technology to access the Web. Three of these technologies include:

While these are not the only assistive technologies used to access Web content, they do represent a large portion of those used by persons with disabilities. When considering the barriers created by Web content, accessibility issues differ somewhat for each group of assistive technology users. For screen reader users the primary issue is access to visual content, that in most cases can be made accessible by providing text equivalents. For text-to-speech users the primary issue is access to columns of text, avoiding the use of, or providing and alternative to columns that presents text in a linear form. For users of alternative access devices, the primary issue is the size of target areas, such as access to navigation buttons, image map areas, or form controls.

Note: There are differences in the support browsers offer for each of the strategies listed. Most are supported by Internet Explorer 4+, the browser most commonly used by assistive technology users.

Top 10 Accessible Authoring Practices

1. Provide Alternative Formats

The most common alternative format is ALT text for simple images or graphics. By including the ALT attribute within the IMG tag, it is possible to provide a short description of an image. For a blind user, this may be the only way for them to know what the image represents. ALT text can be included with an image as follows:

For more complex images that can not be described in 10 to 12 words, a long description can be included on a separate page, then linked from the image. Traditionally these links to alternative descriptions have been called d-links, or description links. You may have noticed on access aware sites the letter "d" scattered throughout the site. Clicking on the "d" takes the user to an anchor point in the long descriptions page. D-links will be phased out in favour of the new "LONGDESC" attribute. The LONGDESC attribute works like a d-link, though the image, or object itself, serves as the link to an anchor on a long descriptions page. The LONGDESC attribute is not yet widely supported so for now it is recommended that d-links be used in addition to LONGDESC. Examples using d-links and the LONGDESC attribute might look like the following:

Where the complex image or object is not already a link, the image itself can be linked to the description, in addition to including the LONGDESC attribute, as shown below:

Though most new technologies are adhering to accessibility guidelines, or developing accessibility features as components of the technology, it will be some time before technologies such as JAVA, or VRML (Virtual Reality Modeling Language), for example, become universally accessible. Sun Microsystems has developed an accessibility API (Application Programming Interface) for JAVA that allows a screen reader user to access the content of a JAVA application or applet if the accessibility features have been included by the programmer. However, most JAVA applets currently found on the Web are inaccessible. When technologies like these are used, an equivalent alternative format should be provided. If, for example, a JAVA applet is used as a client for a Chat facility, a text based equivalent of the client should be provided. Where it is not within the developer's ability to program JAVA applets or VRML worlds in an accessible form, a "d-link" can be used to describe the content of the object. Where critical information is being presented in a programmed object, it should be re-represented along side the object in an equivalent, accessible format.

Alternative formats also include visual presentations of text, essentially the opposite of the above strategies where text has been included as an alternative to visual objects. For some users text can be a barrier if they have difficulty reading, or if text is not in their primary language. A good example of a visual equivalent of text is providing a map to accompany text that describes traveling directions. Similarly, instructions that include a step by step text description, can also include graphical representations of the same steps. It is somewhat more difficult to include visual alternatives to text, but for important instructions or navigation components, presentation should be made in as many formats as possible in order to reach the broadest audience.

A common practice is to create copies of word processed documents in Portable Document Format (PDF) so that the formatting of the document is preserved exactly. PDF files are currently inaccessible to most assistive technology users. An accessible alternative must be included. Tools are available from Adobe that will convert PDF files into HTML format. Developers are warned however, that the output generated through the conversion of PDF to HTML, is not always accessible. Developers should examine the conversion generated markup to ensure it's validity.

A second alternative format accessible to most users is Rich Text Format (RTF). RTF files can be displayed in most current word processors. Developers should be aware that a user may not have a viewer that will display RTF files if, for example, they are accessing the document from a public machine where an RTF compatible viewer is not present or can not be installed by the user. If developers are concerned that users will not be able to view RTF files, they should include an HTML or ASCII text alternative, although the latter strips all formatting from the text they may be conveying meaning (e.g. heading levels, lists, layout etc.)

2. Present Text in a Linear Layout

For many screen reader and text-to-speech users, text presented in table columns creates a significant barrier. Most of these technologies read across the page rather than down through table cells. As a result, the user will hear the first line from the first column, then the first line from the second column, then the second line from the first column, then the second line from the second column, and so on. The resulting audio output is very difficult to understand and in many cases is incomprehensible. The example below demonstrate what a screen reader might read if text is presented in columns.

There are a variety of strategies that can be employed to overcome this problem.

1. The first strategy deals with text navigation links often placed down the left side of a page that has been laid out with a table. When a screen reader or text reader encounters these text links, they are read intermittently with the text content that appears to the right, much like the example shown above. To overcome this problem the text links that appear to the left should be replaced with images of those links. These images should have ALT text included, or better, include redundant text links somewhere else on the page.

2. A second strategy deals with tables used to lay out columnar text. While not inherently inaccessible, content can be made inaccessible if tables are not used carefully. Where tables are used to create columns, text can be placed in the left cell and an image placed in the right, or visa versa. Similarly, wrapping text can be placed in the right cell, and non-wrapping text placed in the left and vertically aligned to the top of the cell as follows:

3. The preferred method for dealing with columnar text layout is to use Cascading Style Sheets (CSS). This allows a user to disable CSS, in which case the columnar layout reverts to a linear layout. Users may also choose to use their own style sheet. Though CSS layout is the preferred method, it may not always be practical, since support for various CSS layout elements differs among Web browsers, and it differs to the point where Web developers become frustrated when trying to produce CSS laid out content that appears identical across Web browsers. In future versions of Web browsers this will be less of an issue. Below is the HTML of a sample page laid out in columns using CSS and the DIV element. Cut and paste the HTML in the example below into a new HTML document, then view the page in a CSS enabled browser (e.g.. Netscape 4.*) with CSS enabled, then disable CSS and reload the page.

In Netscape CSS can be disabled through Edit>>Preferences>>Advanced>> then uncheck "Enable Style Sheets."

There is currently no easy way to disable CSS in Internet Explorer. However, it is possible to create a style sheet then implement it through Tools>>Internet Options>> General>> Accessibility>> then check "Format document using my style sheet".

Other strategies are possible. The intent of any strategy used to format columns, should be to provide viewers with a way to linearize the text of those columns. The W3C has created Tablin, a filter program developed by the WAI Evaluation & Repair (ER) group that can linearize HTML tables and render them accordingly to preferences set by a screen reader user. It is available in different forms at:

Columns laid out with CSS

<HTML>
<HEAD></HEAD>
<STYLE TYPE="text/css">
.center {
	position: absolute;
	top: 120px; 
	left: 150px; 
	width: 240px; 
	height: 100px; 
	padding:10px;}
.right {
	position: absolute; 
	top: 120px; 
	left: 400px; 
	width: 240px; 
	height: 100px; 
	padding:10px;}
.bottom {
	position: absolute; 
	top: 320px; 
	left: 250px; 
	height: 100px;
	width: 600px;} 
</STYLE>
<BODY>
<DIV CLASS="center"> 
<P>
    <STRONG> Creating CSS Columns </STRONG>
    <BR>
    <BR>
    This is some text that would appear in the left column. 
	When CSS is disabled this text would spread across the 
	page and appear before the	text that appears to the 
	right when CSS is enabled.
</P>
</DIV>
<DIV CLASS="right"> 
<P>
        <BR>
        <BR>
 	This is some text that would appear in the right column. 
	When CSS is disabled this text would spread across the 
	page and appear after the text that appears to the left 
	when CSS is enabled
        <BR>
        <BR>
</P>
</DIV>
<DIV CLASS="bottom"> 
<P>
        <A HREF="home.html">Home</A> | 
        <A HREF="contact.html">Contact</A> | 
        <A HREF="news.html">News</A> | 
        <A HREF="resources.html">Resources</A>
</P>
</DIV>
</BODY>
</HTML>

For data tables, table headers should span only a single line. Though it is not widely supported in current browsers, the "ABBR" attribute should be used with the TH element as an alternative, to render header cells in abbreviated form that will be compatible with the next generation of browsers. Where a table header label spans more than one line, the short form included within the ABBR attribute will be read instead of the long header, thus preventing some assistive technology from reading multi-line labels in pieces. The "ABBR" attribute should be used as follows:

The ABBR attribute used to shorten table header labels

<HTML>
<HEAD></HEAD>
<BODY>
<TABLE>
      <TR>   
        <TH>Name</TH>
        <TH>Address</TH> 
        <TH ABBR="Long Label">
        This is a long table header label that may span several
        lines, that gets replaced by the ABBR version when read 
		by a screen reader</TH>   
        <TH>Phone</TH>
      </TR>
      <TR>  
        <TD>John Doe</TD>  
        <TD>10  Lundy Lane, Somecity, T5R 1F4</TD>
        <TD>This cell would contain a long description of 
		some sort that would span several lines, thus wrap when 
		placed in a table cell.</TD>
        <TD>671 555-2314</TD>  
      </TR>
</TABLE></BODY></HTML>

3. Associate table headers with table cells.

Blind users may have difficulty determining which data cells are associated with which header cells. Having to remember the table headers and associate them with table cells is often beyond the limits of most people's cognitive ability. To eliminate the need to remember table headers, headers can be associated with table cells using the "ID" attribute with the TH element, and the "HEADER" attribute with the TD element, as demonstrated in the table below. Also note that the SUMMARY attribute and CAPTION element has been included with the TABLE element to provide additional contextual information that can aid comprehension for a user who can neither see nor scan through the table.

Associating header labels with cell content

<HTML>
<HEAD></HEAD>
<BODY>
<TABLE border="1" width="640"
summary="This table is a list of people who have registered for the
Accessible Authoring Practices workshop. Fields include Name, Address,
a field with a long label, and phone number.">
	<CAPTION> Registration Information</CAPTION>
	<TR>     
		<TH ID="header1" width="10%">Name</TH>
		<TH ID="header2" width="36%">Address</TH>     
		<TH ID="header3" abbr="Long Label" width="35%">
		This is a long label that will 
		span more than one line</TH>   
		<TH ID="header4" width="19%">Phone</TH>
	</TR>
	<TR>  
		<TD headers="header1" valign="top">John Doe</TD>  
		<TD headers="header2" valign="top">
		10   Lundy Lane, Somecity, T5R 1F4</TD>
		<TD headers="header3" valign="top">
		A long piece of text might appear here.</TD>
		<TD headers="header4" valign="top">
		671 555-2314</TD>  
	</TR>	
</TABLE>
</BODY>
</HTML>

The above table example is limited to 640 pixels in width (i.e. width="640") so that wrapping text can be controlled to some extent. You'll notice that after reducing the dimensions of your browser window, the table remains 640 pixels wide, preventing text from wrapping. However, the content of the data cells may not always fit quite as well as the data presented in the table above, and content within cells will often wrap. If wrapping can not be controlled, a linear alternative should be provided, as described in Section 2 above.

Another strategy that can be used for cells that contain longer content is to give these cells their own row that appears immediately above or below the other associated data cells. In the table below the content of the Long Label column has been moved into a row of its own.

Place long cell content in separate rows

<HTML>
<HEAD></HEAD>
<BODY>
<TABLE border="1" width="640"
summary="This table is a list of people who have registered for 
the Accessible Authoring Practices workshop. Fields include Name,
Address, a field with a long label, and phone number.">
<CAPTION> Registration Information</CAPTION>
<TR>     
	<TH id="header1" width="10%">Name</TH>
	<TH id="header2" width="36%">Address</TH>     
	<TH id="header4" width="19%">Phone</TH>
</TR>
<TR>  
	<TD headers="header1" valign="top">John Doe</TD>  
	<TD headers="header2" valign="top">10 Lundy Lane, Somecity, 
	T5R 1F4</TD>
	<TD headers="header4" valign="top">671 555-2314</TD>  
</TR>	
<TR>
<TD colspan="3" valign="top" id="Long_Label"> There would be 
too much content in this cell to contain within a single line, so 
this cell is given its own row so that wrapping text does not 
interfere with a screen reader's ability to read the content of 
the other associated data cells above.
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

4. Provide a way to bypass repetitive content

Almost all well designed sites include a series of navigation links either at the top, or down the side of the page. For a screen reader user, these navigation links can be a source of aggravation, especially when there are many of them. Unlike reading by a sighted person, a blind reader does not have the ability to ignore these navigation links; screen readers read from beginning to end, unless there is a means to skip through the content, bypassing that which these users do not need to hear.

To reduce the amount of unnecessary reading, bypass links can be created prior to repetitive sections. One of the most common strategies is to include an invisible 1x1 gif immediately before the content to be skipped. This invisible bypass link is anchored later on in the page, and has the ALT text, "bypass navigation links", or something to that effect. Similarly, an invisible 1x1 gif can be used to link to alternative navigation tools. For example, if images are used as navigation links at the top of the page, text equivalent alternatives could be included at the bottom of the page and linked from the top via an invisible gif with an anchor just before the text links at the bottom. The ALT text for this latter bypass link might read "bypass content and go to text links at the bottom," or something to that effect.

Create bypass links to skip over repetitive content

<HTML>
<HEAD></HEAD>
<BODY>
<!-- These are bypass links ->
<a href="resources/top_ten.php#content">
<img src="dot.gif" border="0" height="1" width="1"
ALT="Bypass top navigation and go to content"></a>
<a href="resources/top_ten.php#text_nav">
<img src="dot.gif" border="0" height="1" width="1" 
ALT="Go to text navigation at the bottom"></a>
<!-- These are images used as navigation links, that would be skipped 
over if the users selected one of the invisible links above ->
<A HREF="home.html">
<IMG SRC="menua.gif"  BORDER=0 ALT="Home" WIDTH="130" HEIGHT="55">
</A>
<A HREF="contact.html">
<IMG SRC="menub.gif"  BORDER=0 ALT="Contact" WIDTH="130" HEIGHT="55">
</A>
<A HREF="news.html">
<IMG SRC="menuc.gif"  BORDER=0 ALT="News" WIDTH="130" HEIGHT="55">
</A>
<A HREF="resources.html">
<IMG SRC="menud.gif"  BORDER=0 ALT="Resources" WIDTH="130" HEIGHT="55">
</A>
<!-- This is some content ->
<A NAME="content">
<P>Some content would go here. Notice that the first image at the 
top of the page is a 1x1 gif that links to the anchor tag immediately 
before this paragraph</P>
<!-- Below are equivalent text links with a bunch of BR tags to 
create artificial space to make this example functional if cut 
and pasted into a new HTML document then viewed in a Web browser-->
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
<a name="text_nav">
<P>
<A HREF="home.html">Home</A> | 
<A HREF="contact.html">Contact</A> | 
<A HREF="news.html">News</A> | 
<A HREF="resources.html">Resources</A>
</P>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
</BODY>
</HTML>

5. Provide context information

In the table example in section 3 above, the "summary" attribute and the CAPTION element have been used to provide context information. Context information can be included in many ways, in every instance the purpose is to provide a comprehension aid.

If frames are used, the "title" attribute should be included to provide information about the nature of the content in each frame. The most common use of frames is to provide navigation links in one, and a place to open content in another. In such a case the first frame could include title="Navigation Frame," while the second could include title="Content Frame." If a third frame appears across the bottom of the page that displays advertisements, it should include title="Advertisements". In the example below frames and the frameset include the title attribute. In Internet Explorer 4 or later, the frameset title is displayed when the mouse pointer passes over the edges of the frameset. Also note that a NOFRAMES alternative has been included in the example below to accommodate users with browsers which do not support frames. Without the NOFRAMES alternative these users would see nothing when the main frameset is opened.

Title frames and include a NOFRAMES alternative

<HTML>
<FRAMESET COLS="20%, 80%" TITLE="Main frameset for access site">
<FRAME NAME="navigation-frame" TITLE="navigation-frame" SRC="nav.html">
<FRAME NAME="content-frame" TITLE="content-frame" SRC="content.html">
<NOFRAMES>
<BODY>
<P>If frames are not supported then this text will appear. The NOFRAMES
alternative should provided alternative content, or a link to 
<A HREF="alt_content.html">alternative content</A>.</P>
</BODY>
</NOFRAMES>
</FRAMESET>
</HTML>

Context information can also be included with frames using a d-link, or an invisible gif at the top left of each frame linking to another page that describes the content of the frame. Similarly, a d-link placed just before a data table, can be linked to a separate page that describes the content of the table. Alternatively for tables, the content of the table can be summarized in the body of the text that appears on the page containing the table, perhaps describing the layout out the table, and describing its highlights.

In addition to providing context information for tables and frames, similar information can be included for lists, page layouts, or page content. For lists it might simply mean stating the number of items in the list. Instead of saying "...in the list of items below", say "...in the list of 8 items below". Layout can be described on a separate page, outlining where particular features such as image links, content, and text links are located within the page. Context information about the content of the page can be included by creating a list of links at the top of the page, linked to anchors located prior to each major section of the page, or linked to headings located throughout the page, much like a table of contents. The latter strategy is also useful for sighted users, providing them with a quick overview of the page content, and quick links to sections of content that reduces the need to search through a page for a particular piece of information. This strategy has been used with this document, providing a table of contents at the beginning that links to subsections of the page.

Another important form of context information is link text. Many Web content developers use phrases such as "Click here" as link text, which out of context is meaningless. Screen reader users will often use the TAB key to "tab" through the links on a page to gather the gist of its content. When such a user tabs through a page with links specified by the words "click here," they gather no information about the content of the page or the pages linked from that page. Link text should be meaningful, describing what can be found if the link were followed. For example:

6. Explicitly associate labels with form elements and group related form fields.

In many cases explicit labeling of form fields is not necessary, but where complicated forms have been created, or form field labels do not appear immediately above, or immediately before the field, the form field should be explicitly labeled using the LABEL element along with the "FOR" and "ID" attributes. In the example below, notice the use of the FIELDSET element. It has been used to group logically related form fields. Grouping related content can aid memory and comprehension. Within the FIELDSET element appears the LEGEND element, which provides a title for the FIELDSET. The "title" attribute has been used with each form field in place of the usual default characters that should be present in each. In Internet Explorer 4+ the title attribute is displayed when the mouse hovers over the field, and is read by some screen readers in order to explain the expected data to be entered in the field.

The LABEL element has been used to explicitly associate a label "FOR" a field with a particular "ID." With this method the field labels can appear anywhere on the page, and are not restricted to positioning before or above the field. This also prevents labels from becoming fragmented when the size of the browser window decreases, resulting in field labels wrapping over multiple lines. When this occurs, some screen readers will only read the portion of the wrapped label that appears immediately before or above the field, ignoring the rest of the label. Version 4 Netscape browsers do not support the elements and attributes listed in this strategy, but they are supported in the Version 6 browser, which was in the beta phase when this article was written. Internet Explorer 4+ supports them all.

Group form elements and explicitly label those elements

<HTML>
<BODY>
<FORM  name="examples" action="http://www.somesite.com/cgi-bin"
method="post">
<FIELDSET style="width: 640; background: #ffffcc; 
border: solid double blue;"> 
<LEGEND>Account Information</LEGEND>
<TABLE border="1" WIDTH="400">
<TR>
  <TD width="115px"><LABEL for="login">User Identification:</LABEL></TD>
  <TD width="115px"><input type="text" id="login" alt="user identification"
	   title="user-id"></TD>
</TR>
<TR>
  <TD><LABEL for="password">Password:</LABEL></TD>
  <TD><input type="password" id="password" alt="password" 
  title="password"></TD>
</TR>
<TR>
  <TD><LABEL for="pass_confirm">Confirm Password:</LABEL></TD>
  <TD><input type="password" id="pass_confirm" alt="confirm password"
  title="confirm password"></TD>
</TR>
</TABLE>
</FIELDSET>
<FIELDSET style="width: 640px; background: #ffffcc; 
border: solid double blue;">
<LEGEND>Personal Information</LEGEND>
<TABLE border="1" WIDTH="400">
<TR>
  <TD width="115px"><LABEL for="firstname">First name:</LABEL></TD>
  <TD><input  tabindex=4 type="text" id="firstname" name="text" 
  alt="first name" title="first name"></TD>
</TR>
<TR>
  <TD width="115px"><LABEL for="lastname">Last name:</LABEL></TD>
  <TD><input  tabindex=5 type="text" id="lastname" name="text" 
  alt="last name" title="last name"></TD>
</TR>
</TABLE>
<TABLE border="1" WIDTH="400">
<TR>
  <TD WIDTH="100"><LABEL for="gender">Gender:</LABEL></TD>
  <TD><LABEL for="gender_male">Male</LABEL><input type="radio" checked
	 id="gender_male" name="gender" value="male" alt="gender, male"
	  title="gender-male"></TD>
  <TD WIDTH="120"><LABEL for="gender_female">Female</LABEL>
	 <input type="radio" id="gender_female" name="gender_female" 
	 value="female" alt="gender, female" title="gender-female">
	 </TD>
</TR>
</TABLE>
<TABLE border="1" WIDTH="400">
<TR>
  <TD><LABEL for="occupation">Occupation:</LABEL></TD>
  <TD colspan=2>
  <SELECT id="occupation" name="occupation" alt="occupation"> 
  <OPTGROUP label="occupation">
  <OPTION label="generic" value="empty">Select Occupation </OPTGROUP>
  <OPTGROUP label="occupation">
	 <OPTION label="Programmer" value="JuniorP">Junior Programmer
	 <OPTION label="Programmer" value="SeniorP">Senior Programmer
  </OPTGROUP>
  <OPTGROUP label="occupation">
	 <OPTION label="Sales Manager" value="SalesM">Sales Manager
	 <OPTION label="other" value="other">Other
  </OPTGROUP>
  </SELECT>
  </TD>
</TR>
</TABLE>
</FIELDSET>
  <BR><INPUT type=button value="Submit" 
  ONCLICK="alert('This is just an example')"
  title="don't submit">
   <INPUT type=reset title="reset">
</FORM>
</BODY>
</HTML>

7. Use natural language.

Standard usage of acronyms and abbreviations requires the inclusion of their expanded version the first time they appear in a document. However, it is also common practice not to include the expanded version of very common acronyms or abbreviations. In many cases when a screen reader encounters a short form it will try to pronounce the letters as a word, the resulting audio is often unrecognizable. Imagine a screen reader pronouncing FBI, or NFLD. While some assistive technologies recognize common short forms, many do not. To ensure that blind users understand what the odd pronunciation generated by FBI represents, it is important to include it's full version the first time the short form appears on every page. Do this on every page as users may enter your site through different routes, perhaps missing the expanded version that appears on another page. Including the long version with the short form the first time it appears on a page allows a blind user to associate the long form with the pronunciation of the short form, and to make that association the next time they hear the short form.

HTML 4.0 introduced two elements to deal with short forms. Acronyms can be contained within the ACRONYM element. Some screen readers will read the value of the ACRONYM element instead of the acronym itself. The following code demonstrates how the ACRONYM element is used. This element is currently supported by IE 4+ .

The ABBR element is used in a similar way, though it is currently not widely supported. For future reference, when browsers do support this feature, the ABBR element should be used as described below.

For sites that contain many abbreviations or acronyms, a separate page can be used to list them and their long versions. However, providing the long version on every page where they appear is preferred.

8. Design for device independence.

A common access barrier occurs when a user is required to use a specific access device, usually a mouse, to access an element on a Web page. When an element is not keyboard accessible, blind users, and others with mobility impairments, have no way of accessing that element, since they are unable to use a mouse. One common feature found on many Web sites is a drop down selection menu created with Javascript that automatically takes the user to the chosen resource when the selection is made. This eliminates the need to press a submit button. While this may be a handy feature for many users, it renders all choices beyond the first one inaccessible to non-mouse users. When such a user uses the keyboard to scan down through the choices in a drop down list, they are automatically transported to the first choice before they can reach the second choice. To avoid this problem, all drop down choice menus should include a submit button to allow manual control, rather than a script that automatically sends the user to the resource.

Keyboard access attributes have been added to HTML 4.0, and are currently implemented in Internet Explorer 4+. The first is the ACCESSKEY attribute. ACCESSKEYS are commonly added to navigation links to add direct keyboard accessibility to these links. Care should be taken to ensure that the ACCESSKEY chosen do not conflict with shortcut keys used to control browser functions. For example the number "1" can be used as an ACCESSKEY, but the letter "f" cannot. To activate ACCESSKEY requires the ALT key to be depressed at the same time as the designated ACCESSKEY. ALT F would activate the file menu for a browser. In the following example ACCESSKEYS are included in a set of standard navigation links that might appear throughout a Web site. In this example the ALT key is used along with the numbers 1 to 5 to access each link. Notice that the access key brings focus to the link. The enter key must be pressed to activate the link.

A second keyboard access feature in HTML 4.0 is the TABINDEX attribute. TABINDEX works like ACCESSKEY though only the TAB key is used. TABINDEX is often used with form fields. Keyboard users may begin navigating a page by pressing the TAB key repeatedly to work their way in sequence through the links, form fields, or form controls on a given page. When the main functionality of a page is located several links or fields down the page, the TABINDEX attribute can be used to take the user immediately to that point in the page, bypassing all links or form fields prior to it. Once the first TABINDEX has been reached, tabbing after that moves a user through the sequence of links or form field that follow. TABINDEX can be used to provide direct access to links as well as form fields, and the order of tabbing can be altered, not necessarily in sequence. In the following example the user would be taken to the first form field on the first tab, the third form field on the second tab, the second form field on the third tab, and the submit button on the forth tab.

9. Provide alternative navigation.

In order to accommodate as broad an audience as possible, a variety of navigation systems can be included that cater to the users' preferences and cognitive capabilities. Seven possible navigation strategies are described below.

10. Describe the access strategies a site uses.

Once accessibility strategies have been implemented on site they should be described, and this description made easily accessible. A link should appear on the home page early in the sequence of links on that page, so it will be found quickly by a screen reader user navigating the page. Other strategic locations to place an accessibility strategies link include the top of a site map, as one of the first pages in the sequence of pages on the site, as part of the standard navigation links found on every page of the site, or linked from any help information provided with the site.

Top 10 Accessible Web Authoring Practices

Contents

Introduction