Web Course-ware Standards

Introduction

Web based course materials are becoming increasingly important, both for distance education and to supplement traditional classes. This trend has led to an increase in the expectation that these materials will be truly accessible to all students.

The purposes of these standards are:

  • To ensure that UWM's web based course materials comply with federal, UW system, and UWM standards for accessibility to persons with disabilities
  • To maximize the usability of course materials, particularly in distance education environments where students may be using a wide variety of hardware platforms, browsers, and connectivity alternatives.
  • To encourage sound practices in web page design so that the web materials can best support of the course's goals.

Location of Course Materials

There are two approaches to publishing course materials on the web. One is to use a `structured' course-ware server, such as the BlackBoard system supported on campus by the DOT.EDU utility. The other is to publish the materials as `regular' web pages outside of such a structure.

When the structured approach is employed, the particular package used will dictate where the materials will reside on the web.

For course materials published outside of these packages, the recommended location would be in the www.uwm.edu/Course/ area of the main campus server, in a sub-directory created for the particular course. Typically these subdirectories are named for the 6-digit course number. I.e. www.uwm.edu/Course/000-000/

Faculty may also publish course materials in their `personal' web area. However we recommend the /Course/ solution over this option for a number of reasons:

  • It is possible to have an `ownership group' created for a /Course/ area, which can allow more than one person to have write-access to the materials.
  • It simplifies transfer of the materials when responsibility for a course moves to a different faculty member.
  • It keeps the faculty members personal web area separate and available for other purposes.
  • /Course/ is potentially more reliable, since the personal web area could have a lower priority for restoration in the event of an web server outage.
Faculty needing to establish new /Course/ web areas created can contact the I&MT Help Desk (x-4040 or help@uwm.edu) or the Webmaster.

Accessibility

Campus, UW System, and federal policies require that web-based course materials be accessible to persons with disabilities. Unlike with traditional course materials, it is not acceptable to meet this requirement by providing disabled students the equivalent materials on an alternative media.

For example, with traditional course-ware, it might be an acceptable accommodation to provide a blind student an audio tape of material as an alternative to a paper handout. This is permitted since the paper handout would be inherently inaccessible to a blind student. However, a web page is not inherently inaccessible. It only becomes so through poor or incomplete design. Therefore, the only acceptable accommodation for a handicapped student in a web based course is to ensure that the web materials are themselves accessible.

Happily, using practices that ensure accessibility for persons with handicaps also tend to benefit non-handicapped viewers as well.

Sponsorship and Advertising

Generally, University web pages (including course materials) may not include any paid external advertising.

It is usually allowable to include commercial logos or commercial links on course-ware pages for strictly educational purposes. E.g., as examples is an adversing or web design class. However, this might not be a case where there is some sort of financial arrangement with the commercial enterprise, such as them being a grant provider to the instructor.

There are specific rules for what is and is not allowed in cases such as this. Course-ware authors in such a situation should be aware of the relevant rules, available as part of UWM's Policies and Guidelines Concerning the Electronic Publication of Information

Specific Content Standards

  1. HTML Standards: Pages may be created using either the HTML 3.2 or the HTML 4.0 standard. However not all browsers reliably support all 4.0 features. Therefore, pages should avoid unnecesary dependence on HTML features beyond the scope of the HTML 3.2 standard. I.e., web pages that do use features beyond the scope of HTML 3.2, such as JavaScript or Cascading Style Sheets, should be designed to also display and function properly, without loss of content or navigation, on vanilla 3.2 browsers.
  2. All pages should include the complete set of high-level HTML elements (e.g., <DOCTYPE>, <HTML>, <HEAD>, and <BODY>). The HTML tag should include the `language' attribute, which provides useful clues to browsers for hyphenation, rendering special characters, speech synthesis, etc. For an English language document, this would be <HTML LANG="en">.
  3. Each document's <HEAD> element should contain a meaningful and concise <TITLE>. This is the name the page will be indexed under when book-marked by a viewer and is what appears in the browser's `Go' list.
  4. Avoid the use of <FRAME>s whenever possible. They create unnecessary problems for some browsers, they interfere with book-marking of pages, and they limit the ability to cross-link material. (To enforce a common look-and-feel across a set of pages, consider INCLUDEs.)
  5. Avoid blinking or flickering images and flashing text. Such content blinking at certain rates can affect people prone to epilepsy.
  6. Linking:
    • Provide warnings text, indicating size and type of file, when linking to video, audio, or other specialized content.
    • Use meaningful, descriptive linking text. I.e., avoid the use of "click here".
  7. Tables: When displaying tabular data, use the proper <TH> and <TD> elements to distinguish heading and data items. In more complex tables, include appropriate additional HTML (e.g. <THEAD>, <TBODY>, <THEAD>, <COLGROUP>, etc.) to ensure the relationships in the table are properly conveyed.
  8. Using color:
    • Use foreground/background color combinations that have contrasting brightness (not just contrasting colors).
    • Avoid `wallpaper' backgrounds in text display areas. A background's obtrusiveness varies widely depending on the viewer's equipment and also creates problems for persons with certain vision problems such as color blindness.
    • Do not rely on the color of an icon or text as the only way some information is conveyed. If color is a key, ensure that there is also an alternate clue to meaning.
    • Never render text over a photograph or similar image.
  9. Using images:
    • Images should always include an appropriate ALT field that conveys the same information as the image. For images containing text, this should mimic that text. For images used as bullets, horizontal dividing bars, and the like use an ASCII equivalent as an ALT field. For decorative images that do not convey page content, use ALT="".
    • For figures, graphs, and other images too complex to fully describe with an ALT tag, also include a LONGDESC tag containing a complete description of what the image is intended to convey to the viewer.
    • Whenever possible, utilize images of not more than 600x400 pixels. Larger images will require scrolling for many viewers and delays for modem users.
    • JPEG format should be used for photographic or scanned images. For icons, business graphics, maps, and other diagrammatic content with relatively large areas of solid color, GIF format is best.
    • Use of `progressive' JPEGs and `interlaced' GIFs is encouraged for larger images, as this allows viewers to decide early if they need to wait for the entire image to load before moving on.
    • Always supply correct image WIDTH and HEIGHT parameters.
    • Consider utilizing click-able thumbnail images to access larger images.
  10. Using Images Maps
    • When using image maps, be sure the clickable areas will be visually obvious to the viewer.
    • Use client-side rather than server-side image maps whenever possible. If you must use server-side maps, provide an alternate, text-based route to the material accessed via the image map.
    • Include ALT tags on all AREA elements.
  11. Reliance on PDF format documents is discouraged by the the World Wide Web Consortium due, in part, to the accessibility problems they create, particularly for persons with physical limitations. PDF documents can also often be much larger (slower) than the HTML or text equivalent. Use HTML or text format wherever possible. Where PDF format is used, it is good practice to provide an alternate copy in HTML or text format.
  12. Avoid distributing documents in vendor-specific formats (e.g. MSWord®, WordPerfect®). Such files are only accessible to viewers who happen to have that particular software (and often version) available on their system. Most word processors are able to export HTML (or RTF which is easily converted to HTML). Publishing the HTML version makes the document universally accessible.
  13. Multimedia: The use of audio and video content should be done in a way that is accessible to persons with either sight or hearing impairment. In many cases, this may require providing an audio description of the video content or text-based captioning to insure that both the sight and hearing impaired will have complete access to the content.

Resources

The following are some miscellaneous items that can be useful when creating web content.
  • Although following the above standards will help a great deal in making pages accessible by persons with handicaps, there is much more information available on this topic. Those wishing to learn more are encouraged to visit the World Wide Web Consortium for their very complete Web Content Accessibility Guidelines 1.0 and Techniques for Web Content Accessibility Guidelines 1.0 documents.
  • Using an HTML validator, such as Bobby, can help in both insuring your pages do not contain non-standard HTML as well as checking for common problems for persons with handicaps. However passing a validators tests is no guaranty of an accessible page. Many common problems are beyond the diagnostic ability of automated validators.
  • Viewing your pages with a text-only browser, such as lynx (available on the campus Alphas), can give some idea as to how your pages will function on browsers used by the sight impaired. (A good way to check for missing ALTs on images, non-functional image maps, etc.)
  • There are a number of HTML-related utilities installed on the Alphas that can be useful when creating web pages:
    • weblint - An HTML syntax checker
    • tidy - An HTML syntax checker and reformatter
    • html2ps - Converts HTML to PostScript format
    • rtftohtml - Converts Rich Text Format (RTF) to HTML
    • texi2html - Converts Texinfo format to HTML
    • pod2html - Converts perl .pod files to HTML