CSUN  Wordmark
Page Description

The following page is a three column layout with a header that contains a quicklinks jump menu and the search CSUN function. Page sections are identified with headers. The footer contains update, contact and emergency information.

Department of Modern and Classical Languages Banner

(X)HTML Best Practices for ADA Compliance





(X)HTML Best Practices for ADA Compliance

This guide is intended for Faculty and Staff in the Department of Modern and Classical Languages and Literatures who are not regular HTML page creators, but who need to be able to create new pages occasionally and to upkeep pages which are already on-line.

This guide does NOT address the general principles of providing compliant materials that meet standards of the Americans with Disabilities Act (ADA), nor does it deal with the legal aspects that require the production of such materials. To explore such topics, the CSUN Office of University Web Communications has a page with links to both legal resources and training resources in Accessibility Design:


The accessibility page also provides links that make it possible to download various software programs that will help in creation, maintenance and validation processes. These include Macromedia Dreamweaver and the AIS Toolbar.

The College of Humanities Office of Systems and Technology also maintains several pages which can help you with understanding ADA compliance and the tools which are available to make the task easier. These pages can be accessed at:



Long, long ago, when we started to make HTML documents, we were told that the important parts were:


As the years have passed, things have become more complicated. There are now additional items that are essential or highly desirable elements in every (X)HTML document: Many older HTML documents will not Validate because they do not have these items.

  1. The declaration of a document-type. This goes at the very top of the page, before anything else, even before ‹html›. It looks something like this (but it does not appear on the computer screen):

    ‹!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

    If you are using an HTML program (like Dreamweaver, for example) it will put this declaration at the top of every new document automatically, though the exact wording will depend upon what kind of a document you are constructing. This helps a Browser or a Screen Reader to know what kind of document it is dealing with, and how to interpret the mark-up. Also, a document cannot be validated unless it has this declaration. If you are using a University-supplied template, the declaration is already supplied.
  2. The declaration of a character-set, that is, the default type-face that a browser should use in displaying your text. This goes inside the ‹head›‹/head› tags, and it is generically called a meta-tag. The line would look something like this (for an English-language, western character set) (but it does not appear on the computer screen):

    ‹meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"›

    If you are using a University-supplied template, the declaration is already supplied.
  3. You should put in other meta-data, such as who you are and your copyright claim (These do not appear on the computer screen):

    ‹meta name="author" content="California State University, Northridge, Prof. XXXXX, YYYY"›
    ‹meta name="company" content="California State University, Northridge, Department of XXXX"›
    ‹meta name="copyright" content="Copyright (c) 2007 California State University, Northridge"›

  4. Be sure to include a meta-element for the basic language for the page:

    ‹meta name="language" content="en"› for example

    If your principal language is


Language Element
Armenian HY
Chinese ZH
Farsi FA
French FR
German DE
Greek EL
Italian IT
Hebrew IW
Japanese JA
Korean KO
Latin LA
Portuguese PT
Russian RU
Spanish ES

Here is a complete list of Metadata Elements



Be careful of cut-and-paste. In cutting from documents created in word processors, you may inadvertently copy formatting features as well, which may cause Validation problems in an (X)HTML document. This is especially true with smart-quotes. Remember that (X)HTML and CSS documents are text-only documents.

Also be aware that, when you are using a template, you may create problems by cutting material from an HTML 4.01 document and pasting it into an XHTML template.


  1. (X)HTML, CSS, and Validators require that all tags be closed (i.e. those that come in pairs MUST have both pairs written in the code. Most Browsers are very forgiving about this, but Screen Readers and Validators are not. Screen-readers can stall because they are looking for a "close" tag before they can go on to the next "open" tag. With earlier versions of HTML we could get away with this, but not now—and certainly not with XHTML. EXAMPLES:
    • ‹p› must have a ‹/p› to indicate where the particular formatting ends.
    • ‹ul› must have a ‹/ul› to indicate where an unnumbered list ends.
    • ‹ol› must have a ‹/ol› to indicate where a numbered list ends.
    • ‹li› must have a ‹/li› to indicate where a list-item ends.
    NOTE: NOTHING is allowed between a ‹/li› and the next ‹li›. If you want to do line spacing, you must use CSS (line-spacing-before or after) or insert ‹br› tag(s) before the ‹/li›. Sounds strange, but that's the way it works.
  2. XHTML insists that all tag-pairs be closed and some single tags as well. ( e.g. ‹br /› and <hr />)

  3. XHTML insists that all tags be written exclusively with lower case letters.



A screen-reader for the visually impaired reads a table data-cell ( ‹td›‹/td› ) by data-cell. Thus, if you have a 3 X 3 table, the screen-reader will read everything in the first-row-left, then the first-row-middle, then the first-row right, then the second-row-left, second-row-middle, etc. You have to be careful how you arrange your data, so that it makes sense to the screen-reader.

A Table for Office Hours, for example, might be 5 columns by one row. In each cell, the data could be stacked vertically using the ‹br /› tag.

But DO NOT create a Table layout with 5 columns and three rows. The Screen-reader will read, "Monday, Tuesday, Wednesday, Thursday, Friday, 9-10, 9-10, 9-10, 9-10, 9-10, 2-3, 2-3, 12-1."

N.B. The screen-reader is not actually reading the monitor screen. It is reading the (X)HTML markup.


The ampersand is a small character that presents big problems these days. It is a familiar part of the word-processing environment. But it is also part of browser-language and screen-reader-language. Using the ampersand as though you were doing word-processing is no longer acceptable in an (X)HTML document. A screen-reader interprets the ampersand as the beginning of a command; the end of that command will be a semicolon. If there is no semicolon, the screen-reader may pause because it cannot find the end of the command. So, naked & is now forbidden. It comes as part of a pair (&  ;), a pair which does not appear as such on the screen. If you wanted an ampersand to appear on the screen, for example, you would write in the HTML document &amp; This is true even in links to other pages (http://......). If you have an & in the URL, you should add amp; after the & .

The ASCII extended-character set does not Validate in (X)HTML. Some browsers cannot handle them. And they may present problems for a screen-reader. They should be replaced by either the Character Name or the Character Hexadecimal number.

Example: In a word-processor you can write é [ALT 0233], but in (X)HTML you should replace the extended-character with &eacute; or &#233;

You can view and download a chart of the Extended-Character Set from:



There are some tags which are very familiar because of word processing, but when they are used in (X)HTML documents they do not provide the proper help for software programs that "read" for the visually impaired. These tags should be replaced by tags which DO activate features of the Screen Reader programs.


  1. Don't use ‹i›‹/i› for italics. Use ‹em›  ‹/em› for emphasis. The computer monitor will still display italics, but the screen-reader will change the quality of the voice to indicate italics.
  2. Boldface, ‹b›  ‹/b› doesn't produce a response. ‹strong›  ‹/strong› makes the Screen Reader respond. The screen-reader changes its tone-of-voice to indicate to the visually impaired that there is an italicized item or emphasis.

The W3C Consortium has prepared a number of useful summary pages concerning features of HTML that frequently cause difficulty:

For TEXT: http://www.w3.org/TR/html401/struct/text.html


Flashing, moving, or strobing images are not allowed. They cause problems for people with vision problems or with certain kinds of neurological coditions (such as epilepsy).

Every image must have an explanation attached for the benefit of those with vision problems. There must be an "alt" tag in the line of code which points to an image. The "alt" tag may not be longer than 56 letters.


‹img src="http://www.csun.edu/~hcfll004/medusa1.jpg" alt="Caravaggio's Medusa, a circular painting of the Gorgon, snakes in her hair" width="370" height="370"›

Your page will not Validate unless each and every image has an "alt" tag content. You cannot get away with putting the word "image" in each "alt" tag. Validators complain when the same words are used in close proximity.



The best short introduction is to be found in the Wikipedia on-line encyclopedia:


W3C Consortium also has an Introduction: http://www.w3.org/TR/html401/present/styles.html

As does Your HTML Source: http://www.Yourhtmlsource.com/stylesheets/introduction.html



Departmental Offices :
405 & 408 Sierra Tower
Phone: (818) 677-3467
Fax: (818) 677-5797