February 6th, 2002
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
- 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.
- 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">.
- 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.
- 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.)
- Avoid blinking or flickering images and flashing text.
Such content blinking at certain rates can affect people prone to epilepsy.
- 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".
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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
![[ UWM Home Page ]](/UWM/images/home_butn.gif)
![[ Up to Web Policies ]](/UWM/images/up_butn.gif)
![[ Top of Page ]](/UWM/images/top_butn.gif)
![[ Search ]](/UWM/images/search_butn.gif)
![[ Contact Us ]](/UWM/images/contact_butn.gif)
Last update: February 6, 2002. --- URL: http://www.uwm.edu/policy/standards.html
Copyright 2002 by the University of Wisconsin-Milwaukee, all rights reserved.
If you have questions or comments about this page please send e-mail to:
www@uwm.edu