In a constant effort to keep technology accessible to those with disabilities,
this web site uses features that make web pages accessible to blind or low-vision
users utilizing screen readers to access the Web. Such features include:
All images utilize ALT tags for users that have the "Auto-load
Images" feature of their browser disabled. (Users using screen readers
must disable this feature in order for the screen reader to read graphical
links properly).
In
order to be fully compatible with any browser, there are text based
navigational bars at the top and bottom of each document. Any imagemaps used will have an alternate text version of all links.
Although there are currently no content-rich graphics on this page,
Shui Long's fully intends to follow the convention of placing a letter "D"
as a text link next to each content-rich graphic to describe the image
in full detail.
All on-line forms that will be used on this site will include an empty
space as a place holder in order to make fields easier for screen readers
to recognize. There will also always be an alternate version of all forms
that users can download and either mail or email to the department.
Testing accessibility to web pages with both Netscape and Internet
Explorer has found the following: Microsoft's Internet Explorer
from it's early releases as well as the latest (4.0) version of
Netscape (Communicator) are the most "screen-reader friendly".
This means that they correctly use the TAB key to move from link to link
and also read graphical links using ALT tags properly. Since the 4.0 version
of Netscape Communicator is an extremely large program that requires a
powerful computer, we recommend that people using screen readers on systems
with limited resources obtain a lower version of Microsoft's Internet Explorer
at http://www.microsoft.com/ie/download/
Although we are making every effort to make this web page as accessible
as possible, we strongly encourage people to let us know of anything we
may have missed. Please send email to Shui Long if you have any questions or concerns
regarding this web site. We also enjoy compliments as well!
Below is some information about specific issues regarding web page accessibility.
Please note that in no way is this information complete, but is meant only
as an introduction. For more information, please see the Trace
Research & Development Center web page from which this information
is excerpted.
Tabular presentation of text causes problems for people using screen
reading software because text is read by row rather than column. To understand
the problems it is important to know that most screen reading programs
used by people who are blind, read the words on the page to the user one
line at time. That is, they start at the left margin and read straight
across to the right margin. If there are two columns of text, it will read
the words in the left column - and then the works in the right column.
Even users that have screen readers that can read by column might get lost
in a tabular layout if they are unable to determine which column or row
they are in while maintaining their position in the table. Also, pages
that use tables to layout text can be very confusing if not done very carefully.
Solution Strategies:
Avoid arranging text documents in columns .
If it is unavoidable, make a text-only version of the page containing
the table. See the section on tables for more discussion about other types
of tables.
Solution Strategies in the Future:
As we've discussed, there are several different pieces of the puzzle
that can be modified to increase accessibility. In the land of tables,
there is work going on with screen readers, HTML specifications, and browser
support. Screen reader developers are working on techniques to read by
columns, and browsers are emerging that can render tables in a more readable
format. The HTML 3.0 specification includes AXES and AXIS attributes for
cells of a table, which could be queried by a browser to return row and
column information about a specific cell.
People who are blind cannot view information that is presented (only)
in graphic form.
People who are accessing information over a slow network connection
(such as a modem) have only very slow access to pages with graphics if
the auto-load images feature is turned on or no access to the graphic information
if the auto-load images feature is turned off.
If Web documents (or their derivatives) are to be made available via
phone or other auditory channel, then some alternate method for presenting
graphical information is needed.
People who are accessing information with a text-based browser such
as Lynx have no access to graphic information.
Some people want to view graphics, and some others cannot access graphics.
People with manual or cognitive disabilities, people who cannot read,
etc. may have difficulty understanding or interacting with information
that is presented only in text form.
Solution Strategies Today:
Approach 1: ALT-TEXT:
Provide an alternate text description (ALT-TEXT) which would be displayed,
instead of the image, when viewing the page with a text-only browser or
with the "auto load images" feature turned off.
The form for this is:
<IMG SRC="http://www.your.host/filepath/filename.gif" ALT="Alternate
text describing the picture.">
ALT-TEXT Tips and Tricks:
.Keep the wording simple. For descriptions of diagrams or charts see
the following two approaches.
Sometimes it is easier to describe what the function of the graphic
is rather than what it is or looks like.
Using the height & width tags for images may cause the ALT-TEXT
to wrap, which often makes it unreadable by everyone but Lynx users. Some
browsers will support the font size tag. By decreasing the size of the
font, the ALT-TEXT can be made to fit in the specified region.
Include punctuation or spaces at the end of ALT-TEXT of images used
as links, so that several phrases are not strung together. (Link to more
info about the Text Anchor guidelines.)
If the graphic gives the visual user an indication that there is a
change in context, this should be modeled in the ALT-TEXT as well.
For example: the ALT-TEXT for a graphical line might be 'Section 2: today's
weather." But if you have already titled the new section (in some
sort of bold text), don't be redundant, just say 'section 2.' If this is
also contained in the title of the section, then you may just want to use
'-----' or '----2----' or 'horizontal line.'
If you are going to use a horizontal rule for a visual layout of change
of context, a graphical line is recommended rather than the <HR>
tag. This way, the image can have ALT-TEXT. The description should indicate
the function of the line.
The ALT-TEXT used can also indicate a horizontal line for sighted users
with the use of dashes:
For critical bullets, use numbers or letters as the ALT-TEXT so that
they are pronounced.
One of the first items a user encounters on the site should be a description
of what protocol is being used. For example, make it clear that images
without ALT-TEXT do not have any impact on understanding the context of
the page. Some people then like to use nothing as the ALT-TEXT as follows:
<IMG SRC="image.gif" ALT="">
Remember that for the text-based browser or screen reader user, the
image will be unnoticed.
Approach 2: Longer Descriptions (on separate pages, or as footnotes)
By their nature, ALT-TEXT descriptions are usually short and define the
basic purpose of graphic elements. For example "Logo for XYZ company"
or "Picture of ZZZ Center Building". These are instructive but
do not provide very much information about the pictures.
Method 2.1: D-Links:
In order to provide people with additional information, WGBH has pioneered
the practice of placing a capital "D" text anchor next to pictures
or graphics which link to a longer description of the graphic. For example,
"The Logo for XYZ company" consists of a globe with people of
different races all standing out from the globe, holding hands, while a
sunburst shines from behind the earth. The earth is positioned so that no
particular continent is centered on the globe" Descriptions which are
too long for ALT-TEXT descriptions can thus be provided, yet they do not
clutter up the main page.
Since the "D-link" is not a very descriptive link, if you use
this method you should probably include a statement somewhere that describes
what access features you have included so that people know that a capital
'D' will take them to a description of an image.
Another option is to use a more descriptive text anchor, such as "or
a description of xxx."Click here for more discussion and examples of
D-links.
Method 2.2: Transparent images as links to descriptions:
Another option is to create a transparent image as a link to a text description
of the image or a text description at the bottom of the current page.
Approach 3: Alternate pages:
Provide a second version of the page which does not include any inline
pictures for decoration or for anchors. Instead, text descriptions and anchors
would be used. If this is done, a note at the top of each page could allow
users to move back and forth between the graphic and text-only versions
of the page.
It is also helpful to provide an indication of how many items appear
in a list. For example, before a list with six items you could say, "List
with six items."
It is also recommended that you provide the ALT-TEXT tags described in Approach
1 on your "graphic version" of the page. Links to alternate pages
can be implemented as described in Approach 2 .
It is easy to see that creating text-only versions of every page on a
site doubles the number of pages that need to be maintained. Here are three
methods for generating and maintaining text-only pages:
Method 3.1: "By hand"
Sometimes, a site may only need to create text-only pages for layouts
that can not be made accessible. This may only involve a couple of pages.
Method 3.2: Database-based pages:
Create a database-based server that generates HTML pages on demand when
the user asks for them. In this manner, pages can be constructed "on
the fly" either with or without graphics. An example of this is the
CommerceNet server.
Method 3.3: Filter
This approach is similar to Method 3.2, but involves the use of a filter/translator
that would exist on the server as a common gateway interface (cgi). Pages
would be constructed using ALT-TEXT and alternate text pages where needed
and, at the direction of the user, translated into either graphic or pure
text pages on the fly. This method has disadvantages however. Since all
pages must be processed on the fly (as with the database method), there
may be a performance hit unless the filter program is used off-line to create
the text versions of the pages in advance. Secondly, this method would only
work for pages on the server with the AltPage cgi. Whenever references were
made to other pages on other servers, the filter would not work. Image maps
on other servers would be a particular problem unless client-side image
maps were used. Finally, such a filter would create text versions of pages,
but since it would do it by formula, the pages may not be laid out very
well or be very easy to interpret.
Building access into the page or providing alternate pages which are laid
out to make sense in text form (and to provide a text alternative to any
Image Maps) as with Method 3.1 would be much more effective.
Solution Strategies in the Future:
All graphic elements will have a text description as part of the data
structure of the graphic, which can be viewed instead of the graphic. One
example of this is the Portable Network Graphic (PNG) data format.
All browsers will provide the option of showing the graphic, the text, or
both. This should be configurable within the user settings.
Separate Viewer-Based Graphics
Issues:
Often in viewing HTML pages, users will encounter images or anchor phrases
which will fetch and display a large graphic image. This image is often
displayed using a separate viewer in a separate window on screen.
If you cannot see, you have no access to this information.
If you are on a slow network connection, you need to wait a long time
to download the image to see whether or not you are interested in the information
it contains.
If you do not have the proper helper programs, you cannot see the information.
Solutions Today:
The only available approach for providing alternate text for non-embedded
graphics is to provide an alternate data file with the text description
of the graphic in it. (Although some graphic storage formats do allow storage
of text within the data structure, the servers, browsers, and viewers do
not yet allow access to it.)
Approach 1 : (generally recommended)
Place an anchor to a separate page which has a text description of the
picture right next to the anchor that pulls up the picture.
As discussed in the last section, WGBH has instituted the practice of
putting a capital "D" next to pictures or graphics in a document.
If you are using a thumbnail version of the picture as an anchor to the
larger picture, you could use the "D-link" very effectively for
the anchor to the description of the picture.
Approach 2 :
Include a descriptive text anchor to a page describing the graphic, for
example: "or a description of xxx".
Approach 3:
If the user has requested a text-only page, replace all references to
pictures with references to the text files describing them.
In general, Approach 1 is preferred since many users may have asked for
the text-only version because of speed, and may want to view occasional
pictures of interest. Also, even blind users may sometimes want to pull
up a picture to show someone or to have someone describe it to them in more
detail. Both of these are much easier with Approach 1 than with Approach
3.
Solution Strategies in the Future:
Someday, all graphic data formats (such as TIFF, JPEG, PICT or their
successors) will also allow incorporation of text describing the image (very
useful for access and for searching or indexing pictures like PNG). External
or "Helper" viewers could then allow display of the graphic, its
text, or both. Servers could also be able to send the graphic portion, the
text version, or both, on request from the browser. (Java applets could
be programmed to do this today, but it is not a general capability yet.)
Image maps allow users to click on "hot spots" of a picture
which reference WWW pages. This type of feature, which requires an ability
to see and click on particular parts of a graphic image, is completely inaccessible
to people who are blind. Even if the picture is described, they are unable
to detect where to click. Unless a client-side image map is viewed with
a browser that can tab to any active object on the page, such as Microsoft
Internet Explorer.
Image maps are used in a wide variety of ways. Some uses are rather simple
like nice-looking menu bars. Others are more sophisticated, like graphic
representations of maps, diagrams, etc.
Solutions Today:
Today, there are five strategies for providing access. All of them involve
ways to provide text alternatives to the image map's choices, usually as
a listing of text anchors.
Approach 1: (recommended)
Create a client-side image map using alt-text for each of the links.
Several browsers support client-side image maps including Lynx, Microsoft
Internet Explorer and Netscape's Navigator and Communicator. Client-side
image maps are similar to server-side image maps except that the information
regarding all of the links or "hot spots" on the image are sent
to the browser along with the image map picture. If descriptions (a sort
of ALT-TEXT for the image maps links) are provided with the URLs, then browsers
can display the text associated with the links of the image map.
Have an anchor to a text-only page which presents an alternate form of
the entire page. Replace the image map with a list of text anchors of the
URLs available through the image map.
Approach 3: (also good if done in a way which avoids confusion)
Provide a listing of image map choices as a list of text anchors immediately
below the image map. This sometimes works, but it can also be confusing.
The ALT-TEXT of the image map should say that choices are provided in text
form following the image map.
Approach 4:
Instead of using a single graphic as an image map, use a series of several
images that can each have their own ALT-TEXT.
Approach 5:
For each link on the image map create a transparent GIF. The ALT-TEXT
of this image can act as a substitute link for each image map option. Users
who do not view graphics will see all of the image map options, and users
that view graphics will not notice the invisible images.
Background graphics, text colors and colorful images are often used in
the design of Web pages. Although this may make the page appear more attractive
or memorable to some, to others it is not readable.
Solution Today:
Luckily, users can override the source code by changing several configuration
options available in most current browsers. For example, a user can choose
not to load background images as well as choose what color, text, font,
links, and background will appear. (A few formats do exist, such as PDF
and style sheets, where the user is not allowed such control.) Care needs
to be given to this issue by page authors.
Solution Strategies:
Background patterns and color should contrast well with the lettering
to maintain readability (background refers to both backgrounds of pages
and backgrounds of images).
Using dark shades of blue, violet, purple or black lettering on backgrounds
of light shades of blue-green, green, yellow or orange are easiest to read.
Avoid using similar hues together. For example, do not place blue-green
lettering on a blue background (Arditi, 1995).
Select colors that will make your pages easy to read by people with
color blindness. One good test is to see if your pages are readable on
a monochrome monitor.
Make color coding redundant with other means of conveying information.
For example, distinguish glossary words with the color red as well as bold
font.
Keep in mind that not all platforms will display color in the same
manner.
Forms include several types of components such as buttons, edit boxes,
pop-up lists and radio buttons. Currently, some screen readers have difficulty
entering and manipulating form components. Much of this functionality is
being added to browsers, for example, you can now use the keyboard to tab
between all objects on a screen in Microsoft Internet Explorer and Netscape's
Communicator. However, there are still some screen reader and browser combinations
that have problems.
Solutions Today:
For those browsers and/or screen readers that can not identify empty
edit boxes, we recommend using place-holding characters such as a space,
short description or a textual cue. The Trace Web Site Search edit box has
a space included as a place holder.
Since Java is a full-fledged programming language with several issues
of its own, we leave the discussion for how to make Java applets/applications
accessible to another document. Trace recently completed a report commissioned
by Sun to identify the accessibility issues with Java. That report can be
found at http://trace.wisc.edu/java/report.htm
However, not all browsers support java nor do all users want to download
applets because of bandwidth or platform constraints. The newer browsers
support a preferences flag that allows the user to indicate if they wish
to view applets or not.
Solution Strategies:
For viewers that allow the user to block downloading of applets, include
alt-text:
<applet code="HelloWorld.class" width="50" height="100"
alt="This applet displays the words 'Hello World'">
</applet>
For viewers that not do support Java, you can include images or a text
description or a link to another page:
<applet code="HelloWorld.class" width="50" height="100"
alt="This applet displays the words 'Hello World'">
<IMG SRC="Hello.gif" alt"Hello World">
An applet exists in this space that displays the words "Hello World."
</applet>
Add-A-Link *Do you have a disability or web site design guide or tip you think belongs here? Let us know!