Best Practices for Accessibility

Best Practices for Accessibility

F.A.Q. | Glossary

Accessibility Architecture - Web Page Best Practices for Development

This document was developed from the W3C's (World Wide Web Consortium) WAI (Web Access Initiative), using their Checkpoints as its basis. Examples and definitions were taken from other documents on their site. This document specifies the requirements as determined by the Web Accessibility Work Group necessary to make web pages accessible. The work group was comprised of web designers, technical users and non-technical users, from both the sighted and non-sighted community. This group believes following the standards listed below will insure the accessibility of your web pages to the general public, whether or not they are visually challenged or hearing impaired.

Best Practices

The items listed below are considered best practices. You are not required by this document to conform to these standards; however your pages will be considerably more accessible if you do.

Best Practice 1 (based on Check point 1.4)

For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.

Best Practice 2 (based on Check point 3.3)

Use style sheets to control layout and presentation.


Best Practice 3 (based on Check point 3.5)

Use header elements to convey document structure and use them according to specification.

Long documents are often divided into a variety of chapters, chapters have subtopics and subtopics are divided into various sections, sections into paragraphs, etc. These semantic chunks of information make up the structure of the document.Sections should be introduced with the HTML heading elements (H1-H6). Other markup may complement these elements to improve presentation (e.g., the HR element to create a horizontal dividing line), but visual presentation is not sufficient to identify document sections.

Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles, for example.

Note that in HTML, heading elements (H1 - H6) only start sections, they don't contain them as element content. The following HTML markup shows how style sheets may be used to control the appearance of a heading and the content that follows:





<TITLE>Cooking techniques</TITLE>
<STYLE type="text/css">
/* Indent heading and following content */

DIV.section2 { margin-left: 5% }


<H1>Cooking techniques</H1>
... some text here ...

<DIV class="section2">
<H2>Cooking with oil</H2>
... text of the section ...

<DIV class="section2">
<H2>Cooking with butter</H2>
... text of the section ...

End Example.

Best Practice 4 (based on Check point 3.6 )

Mark up lists and list items properly.

Content developers are encouraged to use UL for unordered lists and OL for ordered lists (i.e., use markup appropriately) combined with CSS to provide contextual clues.

The following CSS2 style sheet shows how to provide compound numbers for nested lists created with either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1", etc.

Begin Example:

<STYLE type="text/css">
UL, OL { counter-reset: item }
LI { display: block }
LI:before { content: counters(item, "."); counter-increment: item }

End Example.

Until either CSS2 is widely supported by user agents or user agents allow users to control rendering of lists through other means, authors should consider providing contextual clues in nested lists. The following CSS1 mechanism shows how to hide the end of a list when style sheets are turned on, and to reveal it when style sheets are turned off, when user style sheets override the hiding mechanism, or when style sheets aren't supported.

<STYLE type="text/css">
.endoflist { display: none }

            <LI>Poster paper 
            <span class="endoflist">(End of Paper)</span>
            <LI>Blue writing pens
            <LI>whiteboard pens 
            <span class="endoflist">(End of Pens)</span>
            <LI>paper clips
            <LI>Big lengths of rope.
            <span class="endoflist">(End of Fasteners)</span>
     <span class="endoflist">(End of Office Supplies)</span>

Note: This example does not help the case of wrapping list items. With some more effort, the author could put similar markup at the end of each list item.

Best Practice 5 (based on Check point 3.7)

Mark up quotations. Do not use quotation markup for formatting effects such as indentation. The Q and BLOCKQUOTE elements mark up inline and block quotations, respectively.

Begin Example:

This example marks up a longer quotation with BLOCKQUOTE:

<BLOCKQUOTE cite="">
       <P>Remuneration! O! that's the Latin word for three farthings.
       --- William Shakespeare (Love's Labor Lost).

End Example

Best Practice 6 (based on Check point 4.2)

Specify the expansion of each abbreviation or acronym in a document where it first occurs. Mark up abbreviations and acronyms with ABBR and ACRONYM and use "title" to indicate the expansion:

Begin Example:

<P>Welcome to the <ACRONYM title="World Wide Web">WWW</ACRONYM>!

End Example.

This also applies to shortened phrases used as headings for table row or columns. If a heading is already abbreviated provide the expansion in ABBR. If a heading is long, you may wish to provide an abbreviation, as described in Data Tables.


<TH>First name</TH>
<TH><ABBR title="Social Security Number">SS#</ABBR>

End Example.

Best Practice 7 (based on Check point 4.3)

Identify the primary natural language of a document by using DOCTYP in the header of each html page. It is also good practice to identify the primary language of a document, either with markup (as shown below) or through HTTP headers.

Begin Example:

<HTML lang="fr"> of an HTML document written in French...</HTML>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

End Example.

Best Practice 8 (based on Check point 5.1)

For data tables identify row and column headers. (See 15 above for more information.)

Best Practice 9 (based on Check point 5.4)

If a table is used for layout, do not use any structural markup for formatting. Authors should use style sheets for layout and positioning. However, when it is necessary to use a table for layout, the table must linearize in a readable order. When a table is linearized, the contents of the cells become a series of paragraphs (e.g., down the page) 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 linearization.

Also, when using tables to create a layout, do not use structural markup to create visual formatting. For example, the TH (table header) element, is usually displayed visually as centered, and bold. If a cell is not actually a header for a row or column of data, use style sheets or formatting attributes of the element.

Best Practice 10 (based on Check point 5.5)

Provide summaries for tables. Provide a summary via the "summary" attribute. Summaries are especially useful for non-visual readers. A summary of the relationships among cells is especially important for tables with nested headings, cells that span multiple columns or rows, or other relationships that may not be obvious from analyzing the structure of the table but that may be apparent in a visual rendering of the table. A summary may also describe how the table fits into the context of the current document. If no caption is provided, it is even more critical to provide a summary.

Best Practice 11 (based on Check point 6.4)

For scripts and applets, ensure that event handlers are input device-independent. Provide Alternative text.

Device independent Users must be able to interact with a user agent (and the document it renders) using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and braille devices.

Please note that "device-independent support" does not mean that user agents must support every input or output device. User agents should offer redundant input and output mechanisms for those devices that are supported. For example, if a user agent supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.

Best Practice 12 (based on Check point 7.2)

Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).

Best Practice 13 (based on Check point 7.3)

Until user agents allow users to freeze moving content, avoid movement in pages.

Best Practice 14 (based on Check point 9.1)

Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. When a server-side image map must be used, content developers should provide an alternative list of image map choices.

Begin Example

There are three techniques:

Include the alternative links within the body of an OBJECT element.

If IMG is used to insert the image, provide an alternative list of links after it and indicate the existence and location of the alternative list (e.g., via that "alt" attribute).

<A href="">
<IMG src="welcome.gif" alt="Welcome! (Text links follow)" ismap>
<P>[<A href="reference.html">Reference</A>]
[<A href="media.html">Audio Visual Lab</A>]
If other approaches don't make the image map accessible, create an alternative page that is accessible.

End Example




Best Practice 15 ( based on Check point 9.3)

For scripts, specify logical event handlers rather than device-dependent event handlers.

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:

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. Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):

  • Use "onmousedown" with "onkeydown".
  • Use "onmouseup" with "onkeyup"
  • Use "onclick" with "onkeypress"

Note that there is no keyboard equivalent to double-clicking ("ondblclick") in HTML 4.01.

Do not write event handlers that rely on mouse coordinates since this prevents device-independent input.

Best Practice 16 (based on Check point 10.4)

Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.

Begin Example

Some legacy assistive technologies require initial text in form controls such as TEXTAREA in order to function properly.

<FORM action="" method="post"><P>

<TEXTAREA name=yourname rows="20" cols="80">
Please enter your name here.

<INPUT type="submit" value="Send"><INPUT type="reset">

Provide a text equivalent for images used as "submit" buttons:


<FORM action="" method="post"><P>
<INPUT type="image" name=submit src="button.gif" alt="Submit">

End Example.

Best Practice 17 (based on Check point 12.1)

Title each frame to facilitate frame identification and navigation.

Begin Example

Use the "title" attribute to name frames.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<TITLE>A simple frameset document</TITLE>

<FRAMESET cols="10%, 90%"
     title="Our library of electronic documents">
<FRAME src="nav.html" title="Navigation bar"> 
<FRAME src="doc.html" title="Documents">
     <A href="lib.html" title="Library link">
     Select to go to the electronic library</A> 

End Example


Best Practice 18 (based on Check point 12.3)

Divide large blocks of information into more manageable groups where natural and appropriate.

The following HTML 4.01 mechanisms group content and makes 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.
  • Use tables for tabular data and describe the table with CAPTION.
  • Group table rows and columns with THEAD, TBODY, TFOOT, and COLGROUP.
  • Nest lists with UL, OL, and DL.
  • Use section headings (H1 - H6) to create structured documents and break up long stretches of text. Refer to the following section for more information.
  • Break up lines of text into paragraphs (with the P element).
  • Group related links. Refer to the section Grouping and bypassing links
  • All of these grouping mechanisms should be used when appropriate and natural, i.e., when the information lends itself to logical groups. Content developers should not create groups randomly, as this will confuse all users.


Best Practice 19 (based on Check point 13.3)

Provide information about the general layout of a site (e.g., a site map or table of contents).

A consistent style of presentation on each page allows users to locate navigation mechanisms more easily but also to skip navigation mechanisms more easily 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.

Examples of structures that may appear at the same place between pages:

  • navigation bars
  • the primary content of a page
  • advertising

A navigation mechanism creates a set of paths a user may take through your site. Providing navigation bars, site maps, and search features all increase the likelihood that a user will reach the information they seek at your site. If your site is highly visual in nature, the structure might be harder to navigate if the user can't form a mental map of where they are going or where they have been. To help them, content developers should describe any navigation mechanisms. It is crucial that the descriptions and site guides be accessible since people who are lost at your site will rely heavily on them.

When providing search functionality, content developers should offer search mechanisms that satisfy varying skill levels and preferences. Most search facilities require the user to enter keywords for search terms. Users with spelling disabilities and users unfamiliar with the language of your site will have a difficult time finding what they need if the search requires perfect spelling. Search engines might include a spell checker, offer "best guess" alternatives, query-by-example searches, similarity searches, etc.

Best Practice 20 (based on Check point 13.4)

Use navigation mechanisms in a consistent manner. (See above.)

Best Practice 21 (based on Check point 13.5)

Provide navigation bars to highlight and give access to the navigation mechanism. (See above.)


Best Practice 22 (based on Check point 13.8)

Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

The following writing style suggestions should help make the content of your site easier to read for everyone, especially people with reading and/or ognitive disabilities. Several guides (including [HACKER]) discuss these and other writing style issues in more detail.

Strive for clear and accurate headings and link descriptions. This includes using link phrases that are terse and that make sense when read out of context or as part of a series of links (Some users browse by jumping from link to link and listening only to link text.) Use informative headings so that users can scan a page quickly for information rather than reading it in detail.

State the topic of the sentence or paragraph at the beginning of the sentence or paragraph (this is called "front-loading"). This will help both people who are skimming visually, but also people who use speech synthesizers. "Skimming" with speech currently means that the user jumps from heading to heading, or paragraph to paragraph and listens to just enough words to determine whether the current chunk of information (heading, paragraph, link, etc.) interests them. If the main idea of the paragraph is in the middle or at the end, speech users may have to listen to most of the document before finding what they want. Depending on what the user is looking for and how much they know about the topic, search features may also help users locate content more quickly.

Limit each paragraph to one main idea. Avoid slang, jargon, and specialized meanings of familiar words, unless defined within your document. Favor words that are commonly used. For example, use "begin" rather than "commence" or use "try" rather than "endeavor."

Use active rather than passive verbs. Avoid complex sentence structures.

To help determine whether your document is easy to read, consider using the Gunning-Fog reading measure (described in [SPOOL] with examples and the algorithm online at [TECHHEAD]). This algorithm generally produces a lower score when content is easier to read. As example results, the Bible, Shakespeare, Mark Twain, and TV Guide all have Fog indexes of about 6. Time, Newsweek, and the Wall St. Journal an average Fog index of about 11.


Best Practice 23 (based on Check point 13.10)

Provide a means to skip over multi-line ASCII art. Do not use multi-line ASCII art. Avoid ASCII art (character illustrations) and use real images instead since it is easier to supply a text equivalent for images. However, if ASCII art must be used provide a link to jump over the ASCII art, as follows.


<a href="#post-art">skip over ASCII art</a>
<!-- ASCII art goes here -->
<a name="post-art">caption for ASCII art</a>

End Example.

ASCII art may also be marked up as follows [skip over ASCII figure or consult a description of chart].


% __ __ __ __ __ __ __ __ __ __ __ __ __ __ 100 | * | 90 | * * | 80 | * * | 70 | @ * | 60 | @ * | 50 | * @ * | 40 | @ * | 30 | * @ @ @ * | 20 | | 10 | @ @ @ @ @ | 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 Flash frequency (Hz)

End Example

Another option for smaller ascii art is to use an ABBR element with "title".


<P><ABBR title="smiley in ASCII art">:-)</ABBR>

End Example

If the ASCII art is complex, ensure that the text equivalent adequately describes it. Another way to replace ASCII art is to use human language substitutes. For example, might substitute for a winking smiley: 😉. Or, the word "therefore" can replace arrows consisting of dashes and greater than signs (e.g., -->), and the word "great" for the uncommon abbreviation "gr8".

Best Practice 24 (based on Check point 14.3)

Create a style of presentation that is consistent across pages. Use a minimal number of style sheets for your site.

Use linked style sheets rather than embedded styles, and avoid inline style sheets. If you have more than one, use the same "class" name for the same concept in all of the style sheets.


Accessibility Architecture Resources