- Provide a link to a ãNo Framesä alternative when using frames (FRAMES tag) -- Simply including a NOFRAME tag in your main frame page is not enough. Also be sure that your frame names are descriptive enough to allow for navigation for students using text-mode browsers such as Lynx.
- Always include alternative (ALT tag) text when using graphics and image maps as well as providing text links for site navigation purposes. Also include separate descriptive text when including charts and graphs.
- Use caution when choosing colors for text and backgrounds on graphic images. Those who have low vision can have trouble reading text in graphic images with poor contrast and shades of gray.
- Make sure that items included in a table format (TABLE tag) can be read straight across the screen. If not, you may need to provide an alternative.
- Reduce user confusion by including navigational links on each page of your site and by including explanatory text when needed.
- If possible, sit down with some students with disabilities and have them navigate through the site to give feedback about the siteâs accessibility. More importantly, use their feedback!
Abstract
- The author addresses Web site accessibility issues for persons with
disabilities and discusses alternative design techniques for making them
more accessible. Web design issues addressed include the use of tables,
graphics, frames, navigation and color choice. The author also reviews
several Web-based tools for checking existing sites for their accessibility.
- The media is paying a growing amount of attention about the accessibility
of the World Wide Web for people with disabilities. Assistive technologies
such as screen readers and customized Web browsers struggle to keep up
with the rapidly changing and increasingly complex Web page designs found
on corporate and educational sites alike. Recently, the World Wide Web
Consortium (W3C) announced that they have organized a Web Accessibility
Initiative aimed at increasing awareness for Web designers of the Web design
barriers for the twenty percent of the population who have a disability.
Those of us in the field of education have an added responsibility. The Americans with Disabilities Act (ADA) requires that education be provided in the least restrictive environment. This means that Web-based instructional materials must be designed for use by all students ö including students with disabilities.
As a designer of several Web sites over the last four years that have been used in a variety of courses as well as by academic departments, I began trying to find out what Web design components were particularly inaccessible and how they could be made more accessible by students and faculty with disabilities. Over the past year in my effort to try and answer these questions, I have had the privilege of working with students with disabilities and with personnel of various Web-based instructional initiatives at the University of Illinois at Urbana-Champaign.
- What we found was that the majority of the components that were found
to be inaccessible, were also easy to correct! In addition, when these
corrections are implemented, they will not only increase the accessibility
of the Web sites for students with disabilities but also for those with
slower modem connections or whose computer systems only support lower browser
versions, thereby making these instructional Web pages more universally
accessible.
This paper will present some tips on how to create your future instructional Web sites with accessibility in mind and how to easily check your existing sites for accessibility based on what was learned during the study.
- The students who participated in the accessibility study had a variety
of disabilities such as learning disabilities (including attention deficit
disorder and dyslexia), motor impairments (including muscular dystrophy,
cerebral palsy, and quadriplegia), and visual disabilities (including extremely
low vision and blindness). Because of the wide range of disabilities, it
was possible to get a whole range of feedback about some of the most common
inaccessible Web features. Below is a scenario-based composite of some
of the issues that the participants faced when trying to navigate through
the test sites.
- One of the first problems that we encountered was having to navigate
around the sites that incorporated frames. For students with no arm mobility,
activating one frame over another was a very difficult task. These students
tend to use speech-input devices for navigating through the Web. When arriving
at the sites that used frames, no particular frame was ãin focus;ä that
is, an individual frame needs to be made active in order to take advantage
of any navigational links in the frame. This is similar to having to click
one time with the mouse to activate a particular frame in order to print
the materials inside. However, the several extra steps that were needed
for the students using the voice speech-input devices became slow and tedious
rather quickly. For these students, a link at the top of one of the frames
to a non-frames based alternative would have greatly reduced their frustration.
One of the participants, who was blind, also had trouble with the sites
that used frames. When we went to a site that used frames, we were greeted
with a site that had an inaccessible NOFRAME alternative; that is, the
code that was included for browsers that did not support the use of frames
(such as the text-mode browser, Lynx) only provided us with a set of directives
that informed us that we should be using the latest version of Netscape.
We were left with only these options:
- FRAME: top
FRAME: bottom
- In this case, ãtopä and ãbottomä refer to the names that each frame
was given in the source code. A more descriptive frame name for each such
as ãNavigation Barä and ãMain Frame Windowä would have helped us make a
more confident choice rather than simply guessing. In addition, had the
site designer included a link to an accessible ãno framesä alternative
in the NOFRAMES tag, such as a particular frame URL that could serve as
a main frame, we would have been able to navigate using that as well.
The most prevalent problem we found was the consistent lack of alternative text for graphics and navigational image maps. In one instance where a student was using Lynx, we were greeted with a page that simply had the title of the page and [LINK] [LINK] [LINK] [LINK] [LINK] which were five graphical navigation links that did not include alternative (ALT) text in the image tag (IMG). At this point we had to guess which link was which in order to proceed any further within the site! Had the designer included alternative text for each of the graphic images, we might have been greeted with something like this: Home New Links Search Help. Then, just as with text links to other sites in Internet Explorer or Netscape, we could have just selected the link that corresponded to what we were looking for.
- When we encountered regular graphics without alternative text that
were not linked to other pages, we simply encountered [INLINE] which obviously
was an annoying problem when we tried to differentiate between graphics
on a page filled with [INLINE]âs! Once again, had the designers included
alternative text in their image tag, the [INLINE] would have been replaced
with text such as ãPhoto of the Professorä or ãWelcome to College 101.ä
Occasionally, we ran into problems with the color choices that the site designers choose. A few students with low vision had permanently changed the text and background colors on their Web browsers with colors that were best for them which overrode any of the site designersâ choices. However, changing the colors of the graphic images was not possible. In several cases, the contrast between the text color and the background color on graphic images was extremely poor and the participants had to rely on me to read the text on the images for site navigation purposes.
Another accessibility problem that was not an issue in the sites that we examined but was mentioned by a few of the participants as causing occasional problems was the use of tables to format text. It was brought up that when tables are used as a way of designing a page layout, they can sometimes cause text-mode browsers like Lynx to return a confusing layout with lines of text scattered all around the screen since these browsers do not support tables. This can also be a problem for students with low vision who raise the font size in graphic-mode browsers such as Netscape and Internet Explorer. In addition, tables can be problematic for those who use screen readers with graphic-mode browser versus Lynx (such as students with low vision or severe dyslexia), as most screen readers will read across the screen versus down one column at a time. This primarily occurs when site designers format text into newspaper-style columns or have several lines of text within a single table cell. In many cases, a slight rearrangement of the tableâs contents could have prevented the poor layout in Lynx as well as the popular graphic-mode browsers. In the remainder of the cases, either designing the page without tables or providing a text-only, table-free alternative would have helped solve screen reader problems.
One final problem that was prevalent amongst all of the participants was the difficulties involved with dealing with confusing aspects of site design. One student also pointed out to me that just including alternative text is only part of the solution of inaccessible navigational graphic images, albeit a large part. In a quite a few cases, poor choice in graphic images caused quite a bit of confusion in navigation. In addition, the participants with low vision could not differentiate between one graphic and the next due to the fact that the size of the graphic images could not be raised. In these cases, the inclusion of a text navigational bar would have helped immensely.
- In summary, here are a few guidelines to keep in mind when developing
future instructional Web sites:
- The findings of this study only represent some of the most common Web
features that can be inaccessible. As more and more features are integrated
into a larger number of Web sites, other accessibility issues will undoubtedly
surface. While everyone will not have the luxury of conducting a full-scale
study such as I have, there are several excellent resources available on
the Web to help you in analyzing your own course Web site for accessibility.
- The first and perhaps best known resource is ãBobbyä (http://www.cast.org/bobby),
which is a web site that helps you check your web pages for inaccessible
code. Bobby was developed in 1996 at the Center for Applied Special Technology
(CAST), a non-profit organization dedicated to the research and development
of innovative computer technology with the goal of expanding opportunities
for people with disabilities. When you visit the Bobby site, simply enter
the URL of a page that you want Bobby to analyze and select a browser type
and version (I usually select Lynx, the text-only browser, since many students
with visual disabilities use this browser.). Bobby returns a list of accessibility
and browser compatibility problems, if any, along with the specific code
and line number. You will also get some Hypertext links to suggestions
on why the particular code is a problem and how to remedy any problems
as well as a page download time analysis. If your page follows both required
and recommended accessibility guidelines, then you can include a special
ãBobby Approvedä icon on your page.
- One of the most recent developments has been the Text-Only Maker (TOM)
(http://lunch.ncsa.uiuc.edu/tom/)
developed by Keith Wessel at the National Center for Supercomputing Applications
(NCSA). TOM allows you to create special ãtext-onlyä pages for their graphical
Web pages quickly and easily. TOM can either email the accessible code
for you to use or display the newly created accessible page to you in your
Web browser. After specifying the URL of the page that you want TOM to
look at, you have two choices in how TOM creates accessible pages. The
first option is for TOM to add alternative text to your graphical page.
For instance, you would choose this option if you wanted to make a single
accessible page. The second option is for TOM to create a separate Web
page that can be linked from the top of your page. You might choose this
option if you want to create separate graphics-based and text-only web
pages for your site. At this point, TOM primarily handles alternatives
for graphics but is currently being expanded to include capabilities such
as creating accessible formats for text tables.
- A surefire and often enlightening way to check your pages for accessibility
for students with visual disabilities is to view your pages in a text-mode
browser such as Lynx. Many Internet Service Providers provide Lynx as part
of their Telnet service. However, if you donât have easy access to Lynx,
you can still see what your pages would look like in Lynx using the Web-based
Lynx checker written by Steven L. Baur, entitled ãWhat does your HTML look
like in Lynx?ä (http://www.miranova.com/~steve/Lynx-View.html).
Using this site, you enter the URL of one of your pages and then you will
be presented with a sample screen of what your page would look like if
you were using Lynx. If your page doesnât make any sense this way, you
may need to make some corrections or include a text-only link to your page!
- Finally, I have created a site entitled Considering User Differences:
An Alternative Web Design Guide (http://www.ed.uiuc.edu/people/mhinn/sbd/).
This is an interactive web site that allows designers to examine font and
background color combinations with regards to text readability for those
with low vision, color blindness and reading disabilities. The guide takes
a scenario-based approach in describing the difficulties that many students
may encounter and lets designers view examples which represent particularly
poor font color and background choices. Web designers can then test new
combinations that may be better suited for their site.
In addition to the above-mentioned tools, there are many Web sites with guidelines to making your site universally accessible. For instance, the Trace Research & Development Center (http://www.trace.wisc.edu/world/web/index.html) and the W3Câs Accessibility Initiative (http://www.w3.org/WAI/Activity.html) maintain some excellent resources in this area. But perhaps the most valuable tip that I can offer to keep in mind when designing Web pages that will be used for instructional purposes is this: If your students canât access it, they canât learn from it!
- A special Web site dedicated to the issues discussed in this paper
is available at http://lrs.ed.uiuc.edu/access
Bobby Web Page Analysis Tool from CAST [http://www.cast.org/bobby]
Considering User Differences: An Alternative Web Design Guide [http://www.ed.uiuc.edu/people/mhinn/sbd/]
Text-Only Maker (TOM) from NCSA [http://lunch.ncsa.uiuc.edu/tom/]
Trace Research & Development Centerâs list of Web sites devoted to ãDesigning an Accessible Webä [http://www.trace.wisc.edu/world/web/index.html]
W3Câs Accessibility Initiative [http://www.w3.org/WAI/Activity.html]
What does your HTML look like in Lynx? [http://www.miranova.com/~steve/Lynx-View.html]