Table of Contents

• Introduction
• Getting Started

Checklist

• Easiest
• Intermediate
• Advanced
• Last Resort
• Not Required, But Helpful

Appendices

• Appendix 1: Metadata
• Appendix 2: Tables
• Appendix 3: Forms
• Appendix 4: Scripts
• Appendix 5: Cascading Style Sheets

• Printer Friendly Version

Web Accessibility Checklist For K-State Web Sites

Introduction to Web Accessibility

Have you ever visited a web site that required a browser you do not use, contained text you could not read, or trapped you on a page you could not leave? Sites like these are considered inaccessible.

These sites are inaccessible to users who are visually impaired, can only read large print, have trouble controlling a mouse, have a slow Internet connection, are colorblind, or who use older or hand-held equipment. These sites may also be inaccessible to individuals who have minor physical or technological challenges.

Inaccessible commercial sites lose business; inaccessible informational sites lose their purpose.

by Tim Berners-Lee, inventor of the World Wide Web

The effort to make pages accessible aim at achieving two key concepts: 1) pages need to remain accessible despite any physical, sensory, or environmental constraints or technological barriers; and 2) content must be understandable and navigable through clear and simple language and easy navigation mechanisms.

This guide provides a checklist to help convert or create web pages that achieve these two key concepts. The checklist is divided into several sections, beginning with the easiest moving to the more difficult tasks. The latter half of the guide includes five appendices with detailed discussions of the more advanced or difficult concepts. Examples and supplements are included throughout the checklist.

It should be noted that this guide does not guarantee an accessible web site.

Getting Started

Are you not quite sure where to start with your site? Here are some suggestions to help you get started making your site accessible:

1. Design New Pages with Accessibility in Mind
   Make sure each new page that goes online is accessible. Creating new pages with accessibility in mind will lessen the workload when the other pages are updated and will help you get familiar with accessibility standards and guidelines.
2. Divide the Tasks
   It is easier to get started when the project is divided into smaller goals. Look at the site and divide the project into reasonably sized sections. For example, Goal 1: update the home page, Goal 2: update the second tier pages, etc.
3. Set a Timeline
   Determine a time frame for each goal relative to the size of the task. Complete this for each goal until the entire timeline is determined. Post the timeline and check off each goal when it is achieved.
4. Use the Checklist
   The checklist provides a guide to making web pages accessible. It is divided into several sections beginning with the easiest section and continuing to the intermediate and advanced sections. Start at the beginning and work your way through.
5. Request K-State's Templates
   If you are looking for a simple way to assure the accessibility of the web site, start with K-State's web templates and style sheet. Using the template, information can be inserted into a ready-made design complete with Cascading Style Sheet functions (see Appendix 5 for more information on style sheets). For information on requesting and using K-State templates, see: http://www.k-state.edu/tools/templates/

Web Accessibility Checklist

Easiest Ways to Increase Accessibility

Every page includes the following (or equivalent) statements at the very beginning of the document:

This statement tells the user's browser which version of DTD (Document Type Definition) to use to render a web page. In this case, it is the Transitional DTD, a flexible version that includes some presentation attributes and elements that W3C expects to phase out as support for style sheets matures. There is also a Strict DTD, but most user agents do not adequately support it.

Note: If the page contains frames, then use the DTD statement below instead:

All graphics must have alternate text descriptions (e.g., via "alt", "longdesc", or in element content). This includes every image, Java applet, Flash file, video file, audio file, plug-in, etc. Complex graphics (graphs, charts, etc.) should be accompanied by detailed text descriptions.

The alt descriptions should succinctly describe the purpose of the objects, without being too verbose (for simple objects) or too vague (for complex objects). Alt descriptions for images used as links should be descriptive of the link destination.

Decorative graphics with no other function should have an empty alt description (alt=""), but they should never have missing alt descriptions.

Foreground and background colors provide sufficient contrast when viewed by someone with color deficits. This also applies to graphics. For example, a graphic with a black background should not have navy blue lettering.

No element on the page flickers at a rate of 2 to 55 times per second, thus reducing the risk of optically-induced seizures. To identify possible sources of screen flickering, look at this list of possible causes:

Animated .gifs: Are they essential to the design or can they be replaced with non-animated .gifs? If the animation is necessary, consider that the speed of the animation can be different than intended, because different computers of different processor speeds and different connection speeds can render the animations differently.

Applets: Is the applet necessary?

Any third-party plug-ins: Are they necessary?

Blinking or Scrolling text: These are almost never necessary and should be removed or replaced with static text.

The target of every link is clear. Never use "Click Here" as a link. Instead use "Visit K-State's Web site". If more description is needed and cannot be included in the link, use the title attribute of the <A> tag.

For example:

The page does not cause any pop-ups or other windows to appear and does not change the content of the current window without informing the user.

Note: A user who cannot see a new window being opened can easily become confused and disoriented.

Intermediate

All pages are written in the clearest and simplest language appropriate. For example, always spell out abbreviations at their first use and do not use excessive technical jargon or slang.

All images that convey information have a long description available or the information is repeated in text somewhere on the page.

There is a "longdesc" attribute for <IMG>; however, since not all browsers support it at this time it is recommended that another long description is provided by placing [D] directly after an image with the D linked to the long description. Often the [D] is made invisible by using the same text color as the background. Another option is to use a transparent .gif linked to the description. If this is done, be sure to set the image's alt tag to "D", and it is nice if the title of the <A> tag explains that the link goes to a long description. One or both options are acceptable.

Client-side image maps are used. In addition, provide redundant server-side image maps in support of older browsers. Appropriate alt tags should be used for the image as well as the hot spots.

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

Color is never relied on to convey information.

For example, never use a statement like "Push the red button" or "Wait for the button to turn red." These should be identified by some other means such as "Push the circular red button on the right." Also, graphs and diagrams should not use different colored dots or lines to identify variables. Instead, use combinations of dots, x's, checkmarks, dotted lines, dashed lines, or asterisks.

Note: Not sure if your page meets this requirement? Print the page on a black and white printer. Can the page still be understood?

Each page contains the appropriate metadata. Each page must contain a unique and meaningful title using the TITLE element in the HEAD of the document. Pages should contain a description and keywords. Preferably, each page will contain metadata in the Dublin Core format. For an expanded discussion of metadata and Dublin Core, see Appendix 1.

Pages do not use auto-refresh. For example, do not use "HTTP-EQUIV=refresh". If the page becomes out-of-date frequently, put a note on the web page informing the user to refresh the page periodically for the most current information.

Use header elements to convey document structure. For example, use <H1>, <H2>, and <H3> to show hierarchical structure and not for their presentation style (bold, block display, etc). Always use style sheets to assign these presentation attributes. see Appendix 5 for a discussion of cascading style sheets.

Use lists and list items properly. Make sure you nest LI with OL, UL, and DL correctly. LI = List Item; OL = Ordered List; UL = Unordered List; DL = Definition List.

Use Q and BLOCKQUOTE to mark-up short and long quotations respectively. Do not use them for indentation purposes. To indent a paragraph, use the margin-left property in a style sheet. Quotes delimited by <Q> are automatically given quotation marks by the user agent. You must insert them yourself for <BLOCKQUOTE>.

All changes in natural language are clearly identified. For example, examine the quote below (identifiable by the <Q>).

For a complete list of language codes, see:

All abbreviations and acronyms are spelled out and/or explained at the first occurrence. You can also use <ABBR> tag as below:

This will allow a screen reader to read "World Wide Web" instead of double-u, double-u, double-u, while still rendering it as WWW on the screen.

Each page contains a link to skip over navigation bars. This link can be hidden (make the link the same color as the background) so that only screen readers will notice it. Also, include a link back to the top of the page in case the user decides he/she wants to hear the navigation bar.

All navigation is used in a consistent manner.

A consistent style of presentation on each page allows users to locate navigation mechanisms more easily but also to more easily skip navigation mechanisms to find important content. This helps people with learning and reading disabilities but also makes navigation easier for all users. Predictability will increase the likelihood that people will find information at your site or avoid it when they so desire.

Note: For more information on making tables accessible, refer to Appendix 2.

Tables linearize correctly. When a table is linearized, the contents of the cells essentially become a series of paragraphs one after another. Cells should make sense when read in row order and should include structural elements (that create paragraphs, headings, lists, etc.) so the page makes sense after being linearized. To check this, see:

Tip: To get a better understanding of how a screen reader would read a table, run a piece of paper down the page and read your table line by line, clear across the page.

Layout tables do not have any structural table markup. For example, do not use <TH> or <CAPTION> in layout tables. Only use <TR> and <TD>.

Data tables all have a summary.

Data tables are structurally formatted correctly. For example, the header cells are defined by <TH>.

Data cells are associated with the correct header cells. For examples, see Appendix 2.

Data tables have a caption. The caption is a visible tag shown directly above or below the table.

On pages that require an applet, plug-in, or other application to interpret the page content, there is a link provided to the needed applet, plug-in, or other application.

For example, if the page has PDF files, there must be a link to Adobe's site to download the Acrobat Reader. This also applies to pages that have Excel files or PowerPoint files. Those viewers are available from Microsoft's website.

A style sheet is used for all the presentation aspects of your web page. For information on cascading style sheets, see Appendix 5.

K-State's central style sheet is available to use with a K-State web site. If you create your own, it must be fully compliant with CSS 2.0. To check this, use W3C CSS Validation Service:

Organize the page so it may be read without style sheets.

Style sheets may be used for color, indentation and other presentation effects, but the document is still understandable (even if less visually appealing) when the style sheet is turned off. For directions on how to check this, follow these steps:

Netscape--Edit > Preferences. On the left hand side of the dialog window, select Advanced. Uncheck the menu item titled Enable Stylesheets. Reload page to view changes (F5).

Internet Explorer--Just move the external style sheet to a different location so it cannot be found by the browser. Move it back when you have verified the page is still clear without it.

Relative units are used instead of absolute units for margins, font sizes, borders, etc. whenever possible. For example, use em or percentage lengths instead of px (pixels) or pt (points).

Note: This is not easy, and in some cases it is still necessary to use absolute units until better CSS support for tables is available.

All frames have a title that helps the user understand the frame's purpose. For example, navigation or content.

Note: Frames are not recommended. However, if you feel they must be used, see:

Advanced

All forms are completely accessible and labels are associated with their respective input boxes. See Appendix 3.

Create a logical tab order through links, form controls, and objects. For example, specify the tab order by using the "tabindex" attribute or by ensuring a logical page design.

All audio presentations such as movies have the audio portion captioned, and the captioning is synchronized with the presentation. If the presentation is audio only, then a text transcript is available. This includes live audio and video webcasts.

All applets must have a description. The <APPLET> tag supports an alt attribute but it is only supported in some browsers. An alternative for providing a textual description is to include the alternative text between the opening and closing <APPLET> or <OBJECT> tags.

For example:

Appropriate markup languages are used to avoid unnecessary graphics. For example, for mathematical equations use MathML instead of graphics to represent symbols. For more information on MathML, see:

All pages that require a timed response alert the user to this and allow ample time for the user to request additional time.

Scripts do not interfere with the accessibility of the page. There should be a <NOSCRIPT> alternative for any information that is not available when scripts are disabled. For an example, see Appendix 4.

For scripts and applets, ensure that event handlers are input device-independent. This means that a user may interact with the page with a preferred input--mouse, keyboard, voice, etc. For more information, see Appendix 4.

Last Resort

Text-only versions are meant as a last resort if a page cannot be made 100% accessible. If a text version is available, it is kept as current as the graphical version, and there is a link back to the graphical version from the text-only version.

There are applications available that automatically create text-only versions from a web page, but be sure to check the results, because they are not perfect.

Not Required, But Helpful

Provide keyboard shortcuts to important links. For example, the user could access this link by pushing ALT-K:

Note: Currently, this feature is not supported in Netscape.

Identify the primary natural language of the document. For a complete list of language codes, see:

For example:

Divide adjacent links by more than just white space.

For example, [ Home ] [ Help ] [ Search ] would be fine but Home Help Search could be a problem for screen readers.

Group related links and provide a way for users to skip the group. This can be a hidden link so that only screen readers can detect it.

If a search is used, provide different types of searches for different preferences and skill levels. For example, provide a simple search feature on the webpage, but also provide a link to an advanced search.

Place distinguishing information at the beginning of headings, paragraphs, lists, etc. Like in printed books, use chapter headings and subheadings.

If the document has been split into multiple pages, include a table of contents and information on each page describing which page the user is on in comparison to the total. For example, Page 2 of 3.

Do not use ASCII art if it can be avoided. An example of ASCII art is :) A screen reader would not read this as a smiley face but as "colon open parens". Now imagine a screen reader reading a large ASCII art. If you can not avoid the ASCII art, provide a way to skip it.

Provide abbreviations for long table headers using the "abbr" attribute of <TH>. This will cut down on the reading time of data tables. It also may be rendered by user agents when there is not enough space for the normal <TH> content. Abbreviated names should be short since user agents may render them repeatedly. For instance, speech synthesizers may render the abbreviated headers relating to a particular cell before rendering that cell's content.

For example:

Appendix 1: Metadata

Metadata is a set of attributes or elements that describes the resource. Metadata is essentially data about other data--information about a document, rather than document content. It is recommended that each document at least specify a title, description, and keywords with Metadata. An example of these elements follows:

The META element specifies a property (such as "title"), and assigns a value to it (here, "Mastering Herb Gardening").

Accessibility features of Metadata: The lang attribute can be used with META to specify the language for the value of the content attribute. This enables speech synthesizers to apply language dependent pronunciation rules. Also, when several META elements provide language-dependent information about a document, search engines may filter on the lang attribute to display search results using the language preferences of the user. For example,

For collections or more detailed documents, use of Dublin Core metadata is recommended. Dublin Core (DC) is a standardized set of 15 metadata elements designed to "facilitate discovery of electronic resources" by providing a "common core of semantics for resource description."

Listed below are the 15 standard elements of Dublin Core metadata. Most of the elements can be duplicated. For example, there can be multiple creators.

• Title: A name given to the resource. Typically, a title will be a name by which the resource is formally known.
• Creator: An entity primarily responsible for making the content of the resource. Examples of a creator include a person, an organization, or a service.
• Subject: The topic of the content of the resource. Typically, a subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource.
• Description: An account of the content of the resource. Descriptions may include but are not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.
• Publisher: An entity responsible for making the resource available. Examples of a publisher include a person, an organization, or a service.
• Contributor: An entity responsible for making contributions to the content of the resource. Examples of a contributor include a person, an organization, or a service.
• Date: A date associated with an event in the life cycle of the resource. Typically, date will be associated with the creation or availability of the resource. Use the YYYY-MM-DD format. NOTE: To have your web site recognized by the K-State search engine, use <META name="date" content="YYYY-MM-DD">
• Type: The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content.
• Format: The physical or digital manifestation of the resource. Typically, format may include the media-type or dimensions of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource.
• Identifier: An unambiguous reference to the resource within a given context. Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Examples include the Uniform Resource Identifier (URI) and the International Standard Book Number (ISBN).
• Source: A reference to a resource from which the present resource is derived. The present resource may be derived from the source resource in whole or in part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.
• Language: A language of the intellectual content of the resource. Recommended best practice for the values of the language element is defined by RFC 1766 [RFC1766] which includes a two-letter language code (taken from the ISO 639 standard [ISO639]), followed optionally, by a two-letter country code (taken from the ISO 3166 standard [ISO3166]). For example, 'en' for English plus 'us' for United States, results in 'en-us' for American English.
• Relation: A reference to a related resource. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.
• Coverage: The extent or scope of the content of the resource. Coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and that, where appropriate, named places or time periods be used in preference to numeric identifiers such as sets of coordinates or date ranges.
• Rights: Information about rights held in and over the resource. Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource.

Example:

The following link contains a Dublin Core metadata generator. Plug in an existing web site address and it will make suggestions for DC metadata based on its content. While it is not perfect, it can help to give metadata novices an idea of where to start:

References: Dublin Core MetaData Initiative, http://www.dublincore.org/documents/1999/07/02/dces/

Appendix 2: Tables

Example:

<TABLE summary="This table shows the proper mark-up for accessibility requirements." cellpadding="3" cellspacing="1">
<CAPTION>Caption:  Example of an Accessible Table</CAPTION>
<COLGROUP>
<COLGROUP>
		<COL class="Department">
		<COL class="Title">
		<COL class="Phone">
</COLGROUP>
<THEAD>
<TR>
		<TH SCOPE=col>Name</TH>
		<TH SCOPE=col>Department</TH>
		<TH SCOPE=col>Title</TH>
		<TH SCOPE=col>Phone Number</TH>
</TR>
</THEAD>
<TBODY class="IET">
<TR>
		<TH SCOPE=row>Susan Bale</TH>
		<TD>IET</TD>
		<TD>Webmaster - KSRE</TD>
		<TD>532-1147</TD>
</TR>>
<TR>
		<TH SCOPE=row>Sara Heine</TH>
		<TD>IET</TD>
		<TD>Student - Web Developer</TD>
		<TD>532-2889</TD>
</TR>
</TBODY>
<TBODY class="NEWS">
<TR>
		<TH SCOPE=row>Pat Melgares</TH>
		<TD>NEWS</TD>
		<TD>Unit Coordinator</TD>
		<TD>532-1160</TD>
</TR>
<TR>
		<TH SCOPE=row>Sheran DeMonbrun</TH>
		<TD>NEWS</TD>
		<TD>Office Specialist</TD>
		</TD>
</TR>
</TBODY>
<TFOOT class="footnote">
<TR>
		<TD COLSPAN=4>
This is an example of a footnote.  For IE, it doesn't matter where the <TFOOT> tag is placed in the html.
It will always place the content within the <TFOOT> and </TFOOT> at the end of the table.
This does not hold true for Netscape.
		</TD>
</TR>
</TFOOT>
</TABLE>

View table at: http://www.oznet.ksu.edu/webbuilder/accessibility/guide/tableExample.htm

Appendix 3: Forms

Why do electronic forms present difficulties to screen readers?

Currently, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls. HTML forms pose accessibility problems when web developers separate a form element from its associated label or title.

For instance, if an input box is intended for receiving a user's last name, the web developer must be careful that the words "last name" (or some similar text) appear near that input box or are somehow associated with it. Although this may seem like an obvious requirement, it is extremely easy to violate because the visual proximity of a form element and its title offers no guarantee that a screen reader will associate the two or that this association will be obvious to a user of assistive technology.

How can developers provide accessible HTML forms?

The first rule of thumb is to place labels adjacent to input fields, not in separate cells of a table. For the web developer who does not wish to place form elements immediately adjacent to their corresponding titles, the HTML 4.0 specification includes the <LABEL> tag that lets web developers mark specific elements as "labels" and then associate a form element with that label. There are generally two ways to use the label tag: explicit labels and implicit labels. "Explicit labels" work well Experience has shown that explicit labeling works extremely well with all popular assistive technology and are recommended in all but the very simplest of tables. We recommend that all agencies ensure that their web developers are familiar with these important concepts. Using "explicit" labels involves two distinct steps:

• Use the <LABEL> tag and associated "FOR" attribute to tag labels. In other words, identify the exact words that you want to use as the label for the form element and enclose those words in a <LABEL> tag. Use the "FOR" attribute to uniquely identify that element.
• Use the "ID" attribute in the associated form element. Every form element supports the "ID" attribute. By setting this attribute to the identifier used in the "FOR" attribute of the associated <LABEL> tag, you "tie" that form element to its associated label.

For instance, we have rewritten the HTML code for our simple form-inside-a-table to include explicit labels below. The new HTML code for the explicit labels is indicated in bold:

<FORM>
<TABLE>
<TR>
<TD><B><LABEL FOR="first"> FIRST NAME:</LABEL></B></TD>
<<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME" ID="first"</TD>
</TR>
<TR>
<TD><B><LABEL FOR="last"> LAST NAME:</LABEL></B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME" ID="last"></TD>
</TR>
</TABLE>
<P><INPUT TYPE="SUBMIT" VALUE="SUBMIT">
</FORM>

In a nutshell, that is all there is to making HTML form elements accessible to assistive technology. Experience has shown that this technique works extremely well in much more complicated and convoluted forms.

Avoid using "implicit labels"

With "implicit" labels, the form element and its associated label are contained within an opening <LABEL> tag and a closing </LABEL> tag. For instance, in the table above, an implicit label to associate the words "First Name" with its associated input cell, we could use an implicit label as follows:

<LABEL>
		  <TR>
			 <TD><B>FIRST NAME:</B></TD>
			 <TD><INPUT TYPE="TEXT" NAME="FIRSTNAME"></TD>
		  </TR>
</LABEL>

Experience has shown that implicit labeling should be avoided for two reasons.

First, implicit labeling is not reliably supported by many screen readers and, in particular, does not work well if explicit labels are simultaneously used anywhere on the same web page. Often, the output can be wildly inaccurate and confusing.

Second, if any text separates a label from its associated form element, an implicit label becomes impractical and confusing because the label itself is no longer easily identified with the form element.

Grouping form controls

Content developers should group information where natural and appropriate. When form controls can be grouped into logical units, use the FIELDSET element and label those units with the LEGEND element.

Example:

<FORM action="http://example.com/adduser" method="post">
 <FIELDSET>
 <LEGEND>Personal information</LEGEND>
 <LABEL for="firstname">First name: </LABEL>
 <INPUT type="text" id="firstname" tabindex="1">
 <LABEL for="lastname">Last name: </LABEL>
 <INPUT type="text" id="lastname" tabindex="2">
 ...more personal information...
 </FIELDSET>
 <FIELDSET>
 <LEGEND>Medical History</LEGEND>
 ...medical history information...
 </FIELDSET>
</FORM>

The following HTML 4.01 mechanisms group content and make it easier to understand: Use FIELDSET to group form controls into semantic units and describe the group with the LEGEND element.

Use OPTGROUP to organize long lists of menu options into smaller groups.

Appendix 4: Scripts

How can web developers comply with this provision?

Web developers working with JavaScript frequently use so-called JavaScript URLs as an easy way to invoke JavaScript functions. Typically, this technique is used as part of <A> anchor tags.

For instance, the following link invokes a JavaScript function called myFunction:

This technique does not cause accessibility problems for assistive technology. A more difficult problem occurs when developers use images inside of JavaScript URL's without providing meaningful information about the image or the effect of the anchor link.

For example, the following link also invokes the JavaScript function myFunction, but requires the user to click on an image instead of the text "Start myFunction":

This type of link, as written, presents tremendous accessibility problems, but those problems can easily be remedied. The <img> tag, of course, supports the "alt" attribute that can also be used to describe the image and the effect of clicking on the link.

Thus, the following revision remedies the accessibility problems created in the previous example:

Another technique advocated by some developers is to use the "title" attribute of the <A> tag.

For instance, the following example includes a meaningful description in a "title" attribute:

This tag is supported by some, but not all assistive technologies. Therefore, while it is part of the HTML 4.0 specifications, authors should use the "alt" tag in the enclosed image.

Finally, the browser's status line (at the bottom of the screen) typically displays the URL of any links that the mouse is currently pointing towards. For instance, if a link will send the user to http://www.usdoj.gov, that URL will be displayed in the status line if the user's mouse lingers on top of the anchor link.

In the case of JavaScript URLs, the status line can become filled with meaningless snips of script. Toprevent this effect, some web developers use special "event handlers" such as onmouseover and onmouseout to overwrite the contents of the status line with a custom message. For instance, the following link will replace the content in the status line with a custom message "Click for K-State's web site".

This text rewritten into the status line is difficult or impossible to detect with a screen reader. Although rewriting the status line did not interfere with the accessibility or inaccessibility of the JavaScript URL, web developers should ensure that all important information conveyed in the status line also be provided through the "alt" attribute, as described above.

JavaScript uses so-called "event handlers" as a trigger for certain actions or functions to occur. For instance, a web developer may embed a JavaScript function in a web page that automatically checks the content of a form for completeness or accuracy. An event handler associated with a "submit" button can be used to trigger the function before the form is actually submitted to the server for processing. The advantage is that it saves resources by not requiring the server to do the initial checking. The advantage for the computer user is that feedback about errors is almost instantaneous because the user is told about the error before the information is even submitted over the Internet.

Web developers must exercise some caution when deciding which event handlers to use in their web pages, because different screen readers provide different degrees of support for different event handlers. The following table includes recommendations for using many of the more popular event handlers:

• onClick--The onClick event handler is triggered when the user clicks once on a particular item. It is commonly used on links and button elements and, used in connection with these elements, it works well with screen readers. If clicking on the element associated with the onClick event handler triggers a function or performs some other action, developers should ensure that the context makes that fact clear to all users. Do not use the onClick event handlers for form elements that include several options (e.g. select lists, radio buttons, checkboxes) unless absolutely necessary.
• onDblClick--The onDblClick event handler is set off when the user clicks twice rapidly on the same element. In addition to the accessibility problems it creates, it is very confusing to users and should be avoided.
• onMouseDown and onMouseUp--The onMouseDown and onMouseUp event handlers each handle the two halves of clicking a mouse while over an element--the process of (a) clicking down on the mouse button and (b) then releasing the mouse button. Like onDblClick, this tag should be used sparingly, if at all, by web developers because it is quite confusing. In most cases, developers should opt for the onClick event handler instead of onMouseDown.
• onMouseOver and onMouseOut--These two event handlers are very popular on many web sites. For instance, so-called rollover gifs, which swap images on a web page when the mouse passes over an image, typically use both of these event handlers. These event handlers neither can beaccessed by the mouse nor interfere with accessibility--a screen reader simply bypasses them entirely. Accordingly, web designers who use these event handlers should be careful to duplicate the information (if any) provided by these event handlers through other means.
• onLoad and onUnload--Both of these event handlers are used frequently to perform certain functions when a web page has either completed loading or when it unloads. Because neither event handler is triggered by any user interaction with an element on the page, they do not present accessibility problems.
• onChange--This event handler is very commonly used for triggering JavaScript functions based on a selection from within a <select> tag. Surprisingly, it presents tremendous accessibility problems for many commonly used screen readers and should be avoided. Instead, web developers should use the onClick event handler (associated with a link or button that is adjacent to a <select> tag) to accomplish the same functions.
• onBlur and onFocus--These event handlers are not commonly used in web pages. While they don't necessarily present accessibility problems, their behavior is confusing enough to a web page visitor that they should be avoided.

Some event handlers, when invoked, produce purely decorative effects such as highlighting an image or changing the color of an element's text. Other event handlers produce much more substantial effects, such as carrying out a calculation, providing important information to the user, or submitting a form. For event handlers that do more than just change the presentation of an element, content developers should do the following:

1. Use application-level event triggers rather than user interaction-level triggers. In HTML 4.01, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers.
2. Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):
   1. Use "onmousedown" with "onkeydown".
   2. Use "onmouseup" with "onkeyup"
   3. Use "onclick" with "onkeypress"
   Note that there is no keyboard equivalent to double-clicking ("ondblclick") in HTML 4.01.
3. Do not write event handlers that rely on mouse coordinates since this prevents device-independent input.

Appendix 5: Cascading Style Sheets

Cascading Style Sheets (CSS) is a mechanism for adding style (e.g. fonts, colors, spacing) to web documents. Style sheets work like templates: you define the style for a particular HTML element once, and then use it over and over on any number of web pages. If you want to change how an element looks, just change the style; the element automatically changes wherever it appears. Style sheets allow web designers to quickly create more consistent pages--and more consistent sites.

How do style sheets work?

Say you want to create a page where each instance of <H3> text is green, italicized, and in the Arial typeface. Before the advent of CSS, you had to write the following HTML every time you used <H3>:

But CSS lets you specify this style for all <H3> tags in a single step by defining what is called a selector:

The selector (in this case, the <H3> element) is followed by the style definition, which outlines the style for that selector. The rule font-family: Arial has the same effect as <FONT face="Arial, san serif">; font-style: italic has the same effect as <EM>; and color: green has the same effect as <FONT color="green">. So once the style above is applied to the HTML document, every <H3> element will come out green, italic, and Arial while retaining its inherent HTML characteristics.

For a short guide on using cascading style sheets, see: http://www.w3.org/MarkUp/Guide/Style

For a list of possible style definitions, see the CSS Reference table: http://builder.com.com/5100-31-5071268.html

Applying a style sheet to an HTML document

There are four ways to combine styles with HTML. The two simplest ways are: 1) defining styles in the head or the body of an HTML document, and 2) creating a separate style sheet and attaching it to the HTML file.

The best way to define styles for a single HTML document is within the head of the document. (If you want to create a style sheet for use on several documents, link to an external style sheet instead.) Just place the selectors and their style definitions inside comment tags nested within a <STYLE> element, like so:

<HTML>
<HEAD>
<STYLE type="text/css">
<!--
H3 { font-family: Arial; font-style: italic; color: green }
-->
</STYLE>
</HEAD>
<BODY>
<H3>This is a green, italic, Arial H3 header.</H3>
<P>
<H3>So is this.</H3>
</BODY>
</HTML>

The type attribute of the <STYLE> element defines the type of style sheet being used--in this case, CSS. (At the moment, the only other possibility is "text/javascript" for Netscape's proprietary JavaScript style sheets. In the future, other style sheet languages may be added.)

The comment tags nested within the <STYLE> element ensure that the style rules will not appear or cause errors in older browsers. Any browser that doesn't support <STYLE> will simply ignore the element and the information inside.

Note that the style element must be placed in the document's head along with the title element. It should not be placed within the body.

If you are likely to want to use the same styles for several web pages it is worth considering using a separate style sheet, which you then link from each page. You can do this as follows:

<HTML>
<HEAD>
<TITLE>Linking a Cascading Style Sheet to your web page</TITLE>
<link rel="stylesheet" href="style.css">
</HEAD>

The LINK tag should be placed in the document's <HEAD>. The rel attribute must be set to the value "stylesheet" to allow the browser to recognize that the href attribute gives the web address (URL) for your style sheet.

K-State's cascading style sheet

A central cascading style sheet is available for K-Staters. For more information on the style sheet and using it with your web pages, see: