Unit Banner

Web Best Practices: Accessibility

accessibility iconThe Web Content Accessibility Guidelines 1.0 (WCAG) is a comprehensive reference document for accessibility principles and design by the World Wide Web Consortium (W3C).

Provided below are highlighted Web Accessibility Best Practices by the CSUDH WAM team:

back to topText Equivalents for Images

A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). (508.a) (WCAG 1.1)

Non-text elements include: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video

Image Alternate (Alt) Descriptions

Alternate descriptions are read by screen-readers and appear when an image is unavailable from the server or when the user chooses to "turn-off" or "hide" images in the browser.

Important!: The alt tag is required for ALL images for accessibility.

Image without alternate description:

<img src="../../images/ati_featurepic01.gif" width="100" height="64" />

Image with alternate description:

CSU Icon
<img src="../../images/ati_featurepic01.gif" alt="CSU Icon" width="100" height="64" />

Put the mouse cursor over each image to see the difference.

  • Use "null" value for alt attributes (alt="") for decorative elements, bullets, lines etc. used for visual layout and presentation
    Example: <IMG src="transparent.gif" alt="">
  • Limit text descriptors to convey the information. Example for a photograph alt="Dr. Professor" rather than alt="Photo of Dr. Professor"
  • Use longdesc to convey a fuller description of an image. These are presented on a separate html page. Be sure to provide a mechanism to return to point of origin on the main web page

back to topAcronym and Abbreviations

Use the <acronym> or <abbr> elements to expand short forms in your documents.

<p>The IT manager is responsible for delivering the system</p>

A screen reader will speak this as "the it manager..." and not as "the eye-tee manager..." which is what a sighted person reading it would understand. The following code will make the expanded information available to those who want or need it:

<p>The <acronym title="Information Technology”>IT</acronym> manager is responsible for delivering the system.</p>

You can test this now in Firefox, MS Internet Explorer 5 or later, Netscape 7 or later or Opera v.6 or later. Put the mouse cursor over some text marked up with the acronym or abbr tag and you will see the title= text string appear as a "tool-tip".

The IT manager is responsible for delivering the system.

On this site, we've also added some styling to the acronym element:

acronym {
border-bottom: 1px dotted;

(Note: the support for the <abbr> element is not universal, and so the <acronym> element is preferred)

back to topColor Usage

Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. (508.c) (WCAG 2.1)

How does colored text affect the blind or the visually impaired? What happens to color-relayed information when presented on a monochrome monitor, printed from a black and white printer, read by someone who is color blind or read by a screen reader? The color-coded information is lost.


Here is a list of questions from the final exam. The items in RED are mandatory for an A in the class; the items in BLACK are provided for extra credit.

What is the name of the course?
What is your name?
What is my name?

How many times did you come to class?

Reconfiguring the example will insure that text and graphics convey the correct meaning when viewed without color:

Here is a list of questions from the final. The first 2 items are mandatory for an A in the class; items 3 and 4 are provided for extra credit.

1. What is the name of the course?
2. How many times did you come to class?

3. What is your name?
4. What is my name?

Color is used, however the information is conveyed in a way that relays the importance and layout with dependence on color.

Color Contrast

Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. (WCAG 2.2)

effective and non-effective color contrast sampleBackground color and text color should have a high level of contrast. Persons with low vision, color blindness, monochrome monitors or learning disabilities (and those who don't want to strain their eyes) will have difficulty viewing text if color is not used properly.

The W3C suggests that two colors provide good color visibility if the brightness and color difference between the two colors are greater than a set range, and further provide the following alogrythm for determining sufficient contrast.

Color brightness is determined by the following formula:

((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

Note: This algorithm is taken from a formula for converting RGB values to YIQ values. This brightness value gives a perceived brightness for a color.

Color difference is determined by the following formula:

(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))

The range for color brightness difference is 125. The range for color difference is 500.

Thankfully, there are many free and easy-to-use tools available on the web that assess color contrast and simulate color deficiencies. These tools for web developers are listed in the Web Dev Tools section.

For more information on effective color usage, view the following online guide: Effective Color Contrast (Lighthouse International)

back to topData Tables

  • Use summary attribute of the <table> element to describe the purpose of the table
  • For simple tables use the <th> element with scope attribute to define the row and column headers
  • For complex tables explicitly associate data cells with their row and column headers
  • Use abbrev attribute to shorten header titles

back to topForms

In order to ensure the widest possible usage of forms on your website, the forms must be created with accessibility and usability in mind. There are a number of factors that contribute to the accessibility and usability of forms, including layout, labeling and grouping.

Form Layout

All important information for forms, such as form instructions, must be presented before the form itself. The submit button must be the last form element contained within a form.

Screen readers and other adaptive technology access forms and other HTML content in a linear order. Once a screen reader encounters a submit button, the user generally expects that the form should be submitted. In cases where optional fields, such as radio buttons for changing search criteria, are presented after the submit button, the screen-reader user may not be aware that the options even exist, or will discover them after-the-fact.

Similarly, instructions for a form must be presented before the form. This includes statements about how required fields are denoted or information that the person should be aware of before submitting the form. For example, "This quiz will take approximately 20 minutes" or "In order to complete this form you will require your staff number..."

Labelling Form Fields

All form fields must be associated with their labels using the <label> HTML tag. If a form cannot be labeled, it must include a title that explains in brief what the form field is.

Form fields always have a text-based label indicating what information should be entered into the form field, or what a radio button/check box represents. These labels need to be associated with the actual form field for greatest accessibility. This extra information provides two advantages:

  1. It explicitly associates the field with the label (or provides the equivalent information through the title). This means that when a person is filling out the form using a screen reader, the screen reader will tell the person what the field represents. Without this explicit association, the screen reader software must "guess."
  2. The label text becomes "clickable". When you click on the label, the form field it is associated with receives the focus. In the cases of radio buttons and check boxes, this action will select or deselect the form control. This provides a larger "target" area for clicking, making the form more usable to everyone and especially more accessible to those using voice recognition software or people who have a motor impairment.

For example for a Text Input form control, used to collect an email address, your code would look something like: <label for="email">email address:</label> <input type="text" id="email" size="10" maxlength="30" />

(where the "for" attribute corresponds to the "id" attribute)

In some instances, the label element is not picked up by the user-agent or Adaptive Technology. To address this issue, content authors can also add the title attribute to the form input:

<label for="email">email address:</label> <input type="text" id="email" size="10" maxlength="30" title="email address" />

Results of tests with two assistive technologies show that:

  • JAWS 6.1+ label element and title attribute both work with default reader settings; alt used on anything but the image attribute fails. If title and label are both present JAWS will favor the label.
  • ZoomText 9.0: Label element fails with ZoomText's reader. Title attribute provides most reliable rendering of the purpose of the input.

Manditory Form Fields

All forms should clearly indicate which form fields are manditory prior to the actual form inputs. Avoid cryptic hints such as the use of the asterix or different colors as the sole means of indicating manditory information requirements.

Clear and precise instructions given to the user prior to the form is critical to some end users. One issue to be aware of is that some screen reading software moves into a state known as "Forms Mode", which has an effect of editting or not reading complete instructions embedded within a form.

Grouping Form Controls

Form fields that are logically related should be grouped in a field set. If appropriate, the field set should be labeled with a legend.

Form fields that are logically related should be grouped together. This makes for a more readily understood form, which also helps to make it more accessible.

A typical contact form might look like this:

Contact Details



<legend>Contact Details </legend>

<p><label for="name">Your Name:</label>
<input type="text" name="name" id="name" size="20" maxlength="50" /></p>

<p><label for="familyname">Family Name:</label> <input type="text" name="familyname" id="familyname" size="20" maxlength="50" /></p>

<p><label for="homeaddress">Address:</label> <input type="text" name="home" id="homeaddress" size="20" maxlength="50" /></p>

<p><label for="city">City:</label> <input type="text" name="city" id="city" size="20" maxlength="50" /></p>

<p><label for="phone">Home phone: </label> <label for="areacode" style="display: none;" > areacode</label> (<input type="text" name="areacode" id="areacode" size="3" maxlength="3" value="650" />) <input type="text" name="phone" id="phone" size="15" maxlength="10" /></p>

<p><label for="email">Email address: </label> <input type="text" name="email" id="email" size="20" maxlength="50" /></p>

<p><input type="submit" name="submit" value="Submit" /></p>


The use of a fieldset (<fieldset>) to group form controls will "link" the fields together. In addition to helping people using screen readers, they help other people as well by arranging things logically and grouping them together visually.

back to topFlicker

Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. (508.J) (WCAG 7.1)

Definition: 2 to 55 Hertz = 2 to 55 flashes per second

While flashing and flickering elements often appeal to web designers to draw attention to information, changes and updates, or just to add aesthetic value, returning users and those who endure repeated loops of movement while trying to access needed information will quickly tire of your pages. In addition, causing a page or elements on a page to flash or flicker can have serious effects on users with epilepsy and light sensitivity. Flashing and moving graphics can also be extremely distracting and just plain annoying to other users.

Here is an example of a page with too many flickering elements: North Royalton Police Department (archive). (Note: this page is an archive from February 2003. Visit the updated and much improved site and note the difference: Current North Royalton Police Department).

If you must include flashing or flickering elements on your page, be sure animation changes at a slow enough rate to avoid injury to your visitors. Also, consider timing-out animated elements, so elements stop moving after a certain number of seconds or a specified number of animation loops.

To see examples of different flicker rates, visit the National Center for Accessible Media (NCAM): Examples of Flicker Rates.

back to topScripting Languages: Client-side and Server-side

Often one of the most contentious issues in web site development is the use of Scripting Languages, and the choice between client-side and server-side scripting solutions. Developers must remember that in the spirit of Universal Accessibility, not all user agents will support client-side scripting. For example, older technologies may not support JavaScript, or newer, cutting edge application such as cellular phones, PDAs or similar devices. Occasionally, users may also disable client-side scripting due to security concerns of similar considerations. For this reason all "Mission Critical" scripting MUST reside on the server side for universal accessibility. These include, but are not limited to Search Functions, content inclusion and form validation. This also includes most AJAX driven applications.

While JavaScript should only be used for non-essential functions such as "mouseover" behaviors, when employed, ensure that event handlers are device independent. For example if using "onMouseover" and "onMouseout" also use "onFocus" and "onBlur".

Further Reading:

back to topOther

  • Do not Auto-refresh pages, especially frames
  • Alert user of timed responses, time constraints and provided a mechanism for requesting additional time
  • If needed use a Text-Only Page as alternative page; ensure the alternative page has equivalent information or functionality and is kept updated