Accessible Oakton Web Pages: Key Authoring Concepts
In order to help ensure accessibility for all users of Oakton's public web offerings,
all Oakton web pages should make every reasonable effort to meet W3C.org/WAI Priority
Level One compliance. Pages which cannot meet Priority One should as a last resort
be supplemented by equivalent
means of accessing the information. Alternatives might include such things as
text-only pages or some means of directly and immediately contacting people who
can assist with providing the same information.
The following steps should assist authors in achieving accessibility but WAI
compliance can effectively be determined by examing pages via the CAST
organization's Bobby program . When using Bobby, problems with a page will
be related to a specific line number in the HTML code, which is useful for locating
the source code of problematic elements. If your authoring program does not
display line numbers and you need them to locate a problem, you may find it
helpful to open your page locally in Dreamweaver and switch to HTML view.
General
Current HTML coding (HTML4 at this writing) should be followed at all times.
Text Formatting
HTML is really intended for structuring content more so than formatting
page appearance. Though similar visual effects can be achieved in different
ways, header tags (<H2>, etc.) should be used instead of size/style
tags (<font size="+2">, <B>, etc.). Some assistive browsers allow
users to sort through pages using headers to identify major content sections
so don't fake a structural element like an <H2> tag by using presentation
tags such as <B> and a <FONT SIZE=+2>.
| Examples |
Code |
Visual Effect |
| Correct |
<H2>Replacing Batteries</H2>
Dead batteries should always be disposed of properly. Never place batteries
in an incinerator. Avoid skin contact with leaking... |
Replacing Batteries
Dead batteries should always be disposed of properly. Never place batteries
in an incinerator. Avoid skin contact with leaking... |
| Incorrect |
<FONT=+2><B>Replacing Batteries</></FONT>
Dead batteries should always be disposed of properly. Never place batteries
in an incinerator. Avoid skin contact with leaking... |
Replacing Batteries
Dead batteries should always be disposed of properly. Never place batteries
in an incinerator. Avoid skin contact with leaking... |
Note: The <H2> code, unlike <FONT=+2><B>, will automatically
place a space between the header and the following text section.
Tables
Tables may be used for page layout and still meet Priority One compliance
but style sheets are much preferred and will be required in order to meet
higher priority levels.
Assistive browsers tend to read text left to right, ignoring cell barriers
rather than down one column of cells then up to the top of the next column.
Thus the common practice of laying out a page with a two-column table containing
a menu in the left column and page content in the right column may cause
a page to not be read properly.
Example:
Overview
Syllabus
Week 1
Week 2
Week 3 |
|
Welcome to American History 108. We
will be spending this semester examing
the workings of how presidents are
elected in the United States and the
social... |
The table above, for instance, might be read by an assistive device
like so:
"Overview Welcome to American History 108. We Syllabus will
be spending this semester examining Week 1 the workings of how presidents
are Week 2 elected in the United States and the Week 3 social... "
Tables depicting tabular data must use "table header" code <TH>
(rather than <TD> plus text formating code like <B>) to assist special
browsers to read the data in a sensible manner (rather than like the previous
example).
Example:
The HTML code below will produce the table that follows.
<TABLE BORDER=1>
<TR><TH>Servings</TH><TH>Microwave Time</TH></TR>
<TR><TD>1-2</TD><TD>30 Seconds</TD></TR>
<TR><TD>Contents of Package</TD><TD>1 minute and 30 Seconds</TD></TR>
</TABLE>
| Servings |
Microwave Time |
| 1-2 |
30 Seconds |
| Contents of Package |
1 minute and 30 seconds |
The WAI site has additional guidelines for more complicated
data tables.
Images
All images minimally will use "Alt text" coding. Such code should describe
or reflect the nature of the image. If the image portrays important information,
the ALT text should reiterate it. Images depicting critical information,
such as charts, should use a D-link to text that explains the image in
detail. The D-link is simply the letter D placed near the image and hyperlinked
to a detailed description. In the future, browsers (standard and assistive)
may all allow for the <longdesc> tag but this should be avoided at this
time.
Example 1 (simple image requiring brief description in the alt tag):
The Alt tag reads "Picture of Teacher in classroom"
Example 2 (complex image requiring D-link to long description):
A D-link can point to a supplemetary description on a different page
or target text on the same page.
D
Links - imagemaps
Imagemaps are graphics that have "hotspots" which, when clicked, direct
browsers to other areas of the page or other pages. Some current browsers
with images turned off may not display the hot spot links as individual
clickable links, thus rendering the imagemap useless to some people. Note
further that client-sied imagemaps (by far the most common on Oakton's
various servers) are generally much more accessible that server-side imagemaps
and are the more likely of the two methods to become even more accessible
as assistive technologies evolve.
All imagemap hyper links must be supplemented by redundant text links.
Such alternate text links must be grouped together in a similar distribution
to the imagemap somewhere on the same page on which the imagemap appears.
It should be all right to locate the text link groupings at the bottom
of the web page even if users must scroll there. For an example, see the
Admissions and Registration index page (which has two imagemaps) at http://www.oakton.edu/admiss.
Imagemaps require two types of alt text: One for the image itself and
another (multiple) for each of its hotspots.
The alt tag for the image should direct users to the location of the
supplemental text links.
Example:
<img src="navbar3.gif" alt="Navigation bar for the Admissions pages
- text links at page bottom" usemap="#navbar3">
Text links
Text links must reflect the context of what the user will be linking to.
Avoid "Click here" and "Enter" - type links
Example:
(Bad) Learn more about web accessibility rules. Click
here.
(Better) Learn more about web
accessibility rules.
Color Combinations - Text to Background
Poor text-to-background color combinations can make pages difficult to
read even for non-disabled people. People with varying degrees of visual
impairment including color blindness may find poor combinations impossible.
While many browsers are capable of substituting user preferred color combinations
for those coded by the author, it is best to offer high contrast text-to-background
color combinations at the authoring level rather than forcing users to
do the work.
Examples of difficult to read combinations:
| Your Text Here |
Your Text Here |
Your Text Here |
Frames
Frames essentially combine two or more web pages into a single browser
window where the pages in each frame may interact. A typical use is to
have a menu frame commanding changes in a content frame. Frames should
be avoided since many assistive browsers have difficulties with navigating
them. If used, minimally a frameset should use the <NOFRAMES></NOFRAMES>
code to direct certain types of browsers to alternative pages where content
is presented in a single web page. Additionally, the frameset page should
use descriptive titles for the targeted pages.
Example of naming frames:
Bad: <FRAME SRC="pagemenu.htm" NAME="LEFT">
Better: <FRAME SRC="pagemenu.htm" NAME="menuframe">
Scripts/Forms
Many people with disabilities, even using assistive technology, will have
a difficult time using script applets, including web-based forms. Alternatives
for all actions and transactive applications should be in place. For instance,
if a form is used, provide an email address for people to use instead of
the form for acquiring or submitting information.
PDF (Portable Document Format) files
While Adobe Acrobat PDF files seem to take original word processing or other hardcopy
documents and render them similarly on the web, they are essentially large graphic
files that only depict text and cannot be read by many user agents. When using
PDF files cannot be avoided, links to the Adobe accessibility web site where PDF
files can be submitted for interpretation must be provided. At the Adobe web site,
users can submit the URL for the PDF page and a text version of the page will
be returned to them. The text version returned to the user is not perfect, resembling
what one might get in scanning a wordprocessing document. Tablular data in particular
gets jumbled. Images embedded in the PDF document cannot be "read."
Misc.
No blinking elements or flashing/flickering screens. These things may be
difficult to handle on special browsers and user agents. They may also
cause seizures in users with photosensitive epilepsy.
Avoid opening child windows. It's generally much better for links to
replace the content of the current page with the content of the new page
in the same window.
If color plays an important role in conveying information, for example
if users are directed toward a section of text highlighted in red, make
sure that colorblind users can access the targeted content just as easily
as anyone else.