2001 Conference Proceedings
Go to previous article
Go to next article
Return to 2001 Table of Contents
UNDERSTANDING WEB PAGE ACCESSIBILITY: A FOCUS ON ACCESS FOR
THE VISUALLY IMPAIRED<>
Aaron Smith
GW Micro
725 Airport North Office Park
Fort Wayne, IN 46825
219/489-3671
aaron@gwmicro.com
With the advancement and evolution of web page design, many
sites that take advantage of new technology are quick to be
labeled as inaccessible without understanding how the web page is
designed to work. At the same time, web masters are often quick
to implement the latest in web technology without investigating
any limitations that may arise. By examining and critiquing the
elements of web page design, both web masters and users can work
together to create web pages that offer complete and barrier-free
access to any and all information available.
Accessibility has become a very large and broad term just within
the past few years, and encompasses a number of different groups
of individuals: mobility impairment, visual impairment, hearing
impairment, learning impairment, and others. Each of these groups
has special needs that are required for access. For example, some
with mobility impairments require lifts, or elevators, to offices
above the first floor of a business. Some with visual impairments
require screen readers for access to computers. Some with hearing
impairments require visual cues when a nearby phone rings. Other
groups require other forms of adaptation in order for them to
achieve access.
When contemplating the design of a web page, it is difficult to
think of each type of disability, and account for them during the
design process. Fortunately, for most users, the adaptation
required is minimal, and access can be gained at almost any
location. For others, however, access can be dependant on a
number of different factors. Those with visual impairments, for
example, rely on the web page itself to be accessible, as well as
their screen reader to take into account the elements of web page
design. Certain web pages, however, implement elements that have
the potential to be inaccessible. Is this inaccessibility the
fault of the web master or the screen reader manufacturer?
In order to understand the reasons behind a page considered
inaccessible, web page elements and their characteristics need to
be examined by all parties involved: the web master, the screen
reader manufacturer, and the end user.
A basic web page consists of ASCII text code referred to as HTML
(Hypertext Markup Language). This language contains tags that
indicate to a web browser how a page is to be displayed. There
are tags for bold text, italic text, underlined text, paragraph
breaks, line breaks, tables, forms, frames, and a host of other
ways of manipulating the text on a page. Web pages may also
contain other languages to assist in how the page acts or reacts
to user input. Some of those languages include JavaScript,
VBScript, JAVA, XML, CSS, and DHTML. Web masters decide which
language will provide them with the results they are looking for
while designing a web page. Screen reader manufactures also must
take into account each of these languages, and how their reader
will interact with a page designed in, or utilizing, a certain
language. Understanding HTML, however, is critical to
understanding other languages, and will contain most of the
information that the web browser and screen reader will
communicate to each other.
The following is a list of HTML elements that some accessibility
tools deem inappropriate for an accessible web page. Each of
these elements will be looked at in detail, in relation to design
and screen readers, to examine the possibility of conflict, and
to see if solutions are available.
Because GW Micro is conducting this presentation, the screen
reader of choice will be Window-Eyes. All information regarding
web page access will be drawn upon the features of
Window-Eyes.
FRAMES
Frames are often used to denote a static location for topical
links on a given web page. The most popular frame design consists
of two frames: one frame, containing the aforementioned links,
and another frame where the main content of the site will be
displayed when a link is clicked.
Pros: Frames can be very beneficial for grouping related content
on a web page.
Cons: Frame access (moving between frames) can be difficult to
traverse.
Frames require a document source by default. The document source
is the URL to an HTML document. Although web designers can do
their part by adding a NAME element to a frame, screen reader
manufacturers are able to take this one step further. For
example, Window-Eyes will read the title given to an HTML
document that is loading into a given frame as the name of the
frame, providing the user with a dynamic title every time a new
page is loaded into that frame. If the HTML document had no
title, then Window-Eyes would resort to reading the name given
specifically to that particular frame (this requires the web
designer to add the name element). If neither a frame name nor an
HTML document title is given, then Window-Eyes will announce
“untitled” as the frame name. This is an instance
where the screen reader manufacturer took extra steps in making
sure that the user would always be notified of the presence of a
frame, regardless of whether the frame or HTML document was named
by the web designer. (Note: this section also includes
IFRAMES).
[example]
FORMS
Forms are designed to allow users to input information, and have
that information transmitted to wherever the web page specifies.
Popular examples of forms are order forms, search engines, and
web based e-mail.
Pros: Forms allow users to conduct online tasks quickly and
easily
Cons: Form controls can be difficult to traverse if they are
labeled incorrectly.
Forms consist of controls such as edit boxes, check boxes, radio
buttons, combo boxes, list views, text areas, and buttons.
Creating a form that is accessible requires forethought on both
the web designer’s and screen reader manufacturer’s
part. When a web designer inputs a control into a form, the must
also provide an indication as to what that control is. If an edit
box, for example, has no field label, there is no way for a
screen reader to know what that edit box should be called. On the
other hand, the screen reader must be able to detect a field
label and read it correctly to the user. Although advancements
have been made in web design that allow web masters to provide
labels more efficiently, many screen readers must still be able
to track a field label that is close to a control in order for
the label to read correctly.
[example]
TABLES
Tables are a collection of horizontal and vertical cells
containing information that is relative to a column and row
header. The most common form of a table is a spreadsheet.
Pros: Provide quick access to large groups of information.
Cons: Can be difficult to determine location in a table.
Tables are unique in that they serve multiple purposes. While
tables can contain formatted information (such as a spreadsheet)
they are most commonly used to created web page layout. Cells
begin to contain groups of data, rather then single pieces of
information. Many web designers use tables to align images, and
to combine links into groups of links. If a table contains
structured data, in say a textual graph, then it will be useful
for the user to be able to determine where in the table they are
currently residing. If a table is being used for the placement of
images, however, the cell coordinates contain little or no useful
information at all. Allowing a table to be accessible is
dependant on both the web designer and the screen reader
manufacturer. Web designers can add special tags to table headers
and rows, and the screen readers can pick up on those tags to
provide information as to the location of the currently active
table cell.
[example]
JAVASCRIPT
Many people confuse JAVA and JavaScript. It should be noted that
they are two very different languages, and the only thing that
they have in common is the word JAVA. JavaScript is a web
programming language that allows for a more dynamic and
interactive web page.
Pros: JavaScript is very powerful, and provides several
accessibility aids.
Cons: JavaScript, when used inappropriately can cause a web page
to become inaccessible.
JavaScript is mostly used for the manipulation of color, like
the background color of a link when the mouse passes over it. But
one of the more powerful features of JavaScript is the use of its
accessible features. One such feature allows a key press to
perform certain actions. For example, if a page contains a JAVA
applet that is not accessible, the web designer can implement a
JavaScript key press to perform a task that would bypass the JAVA
applet, thereby creating access. Screen reader manufacturers may
need to take into account the different results that JavaScript
functions can have. For example, JavaScript can be used in
conjunction with DHTML to create dynamic text on a page that
changes under certain circumstances. A screen reader must be able
to tell when that content has changed, and voice the change
accordingly.
[example]
CSS
Cascading Style Sheets are extremely popular for manipulation the
styles of elements on a web page. Elements like font family, font
size, font color, placement, padding, borders, and special
filters can all be applied to make web page more exotic.
Pros: Rarely causes inaccessibility; Powerful features.
Cons: Little implementation among screen readers.
A page that takes advantage of CSS is not only aesthetic, but
aural as well. CSS includes a number of styles that can dictate
the way a web page is supposed to sound. These elements can
affect speech rate, pitch, tone, spelling, and pronunciation. A
web designer could state that a block of text is spoken slower so
that important information is not missed. Screen reader
manufacturers, however, need to take into account that these
elements may exist, and must look for them, and take advantage of
them when they do.
[example]
There are other forms of web page design that can be discussed.
The bottom line is that both web masters and screen reader
manufacturers must be able to understand why a web page works the
way that it does. Often, web designers will use HTML editors that
show the page as it is being developed. This is a fine way to
design a page, but the problem lies in the fact that the designer
may not become familiar with the code use to render the page.
Understanding the code provides the designer with knowledge to
fix accessibility problems that the editor may not understand.
Screen reader developers must also learn to interpret what the
code is telling a web page to do. Have this knowledge will
provide the screen reader with the ability to take into account
many things that were once considered inaccessible.
There are many tools available to examine a site and provide
feedback to whether it is accessible or not. Although these tools
are valuable, they are not an end all nor are they the final say
on accessibility. The only way to understand whether a web page
is accessible is to have a number of different people try it out
with their own respective screen readers. Simply because a web
page causes problem in one screen reader, doesn’t mean that
it will cause problems in another screen reader. Although the
goal is to be accessible for everyone involved, it is also the
responsibility of the screen reader manufacturer to provide
solutions.
Through education, and an increase in web design knowledge, and
by incorporating accessibility into the design paradigm, web
pages can easily become accessible without sacrificing and of the
page’s functionality. Web designers need to become more
familiar with the code that they develop, and screen reader
manufacturers need to before more familiar with how web pages
work. With these two forces combined, an inaccessible web page
will soon become a thing of the past, and technology will once
again be available for all
Go to previous article
Go to next article
Return to 2001 Table of Contents
Return to Table of
Proceedings
Reprinted with author(s) permission. Author(s) retain copyright.