Web Accessibility: A Brief History

snailyakSecurity

Nov 5, 2013 (3 years and 8 months ago)

76 views

All Access

An Introduction to Web Accessibility, Web Standards, and Web Standards Makers

By
Nina McHale

Assistant Professor, Web Library

University of Colorado Denver

Nina.McHale@ucdenver.edu


[Editors Note:
JWL

is pleased to add
All Access

to our lineup of regular columns!

All Access

will
alternate with
Global Connections
each issue.]


Librarians and libraries have long been committed to providing equitable access to
info
r
mation
.
In the past decade and a half, t
he growth

of th
e Internet

and

the rapid increase
in
the
number

of online library resources

and tools

ha
ve

added a new
dimension

to this core duty of our
profe
ssion:
ensuring
accessibility

of online resources to our users

with disabilities
.

The first step
in

this undertaking is
gain
ing

an understanding of the
Web

standards that detail the ways in
which online resources can be made

accessible to those who use assistive technology such as
screen readers.

T
his inau
gural
All Access
column
briefly review
s

the
history of basic accessibility
issues and the
two major sets of

Web

standards

and their makers: the United States Federal
Government

s
Section 508 and

the World Wide Web Consortium

s

W
eb
C
ontent
A
ccessibility
G
uidelines (WCAG)
.


Web Accessibility: A Brief
History

While our users with low or no vision may not appear to constitu
te a significant portion
of the
day
-
to
-
day
customer base in libraries, t
he World Health Organization
(2006)
estimates that
there are 161 million people with vision loss worldwide, and
of these, 137 million are blind
.

The
American Foundation for the Blind
(2011)
estimates that 25 million people in the

United States
have vision loss;

moreover, the aging Baby Boomer demographic will
likely

increase this

number in the coming years.

In addit
ion to
those

with

complete or partial

vision loss, individuals

with
learning, cognitive,
developmental,
and physical disabilities rely on

assistive technology

to
acquire and
use
online information

as well
.

With the advent of screen reading technology
,
the

W
eb should
have

made

inform
ation
more accessible to users with disabilities
.

The text
-
only W
eb browser Lynx

(
http://lynx.isc.org/
)

was popular among individuals with visual disa
bilities after

it was
made available

to the public
in
1
99
3
.

Early
Web

pages, w
hich were
text
-
heavy and not very complex
,

could be

read easily
through

Lynx

s

text
-
to
-
speech feature. However, the increasingly graphic nature of the
Web

introduced a problem:

early
lack of support for cascading style sheets
(CSS)
across
Web

browsers lead

designers and
developers to rely heavily o
n table
-
based layouts for positioning
pieces of content on the screen. Table
-
based layouts caused the content contained in the columns
and rows in the layout table to be read from left to right and top to bottom;
this is not always the
order in which the c
ontent on a

page
should
logically

be

consumed.

Great
er browser support for
the second version of CSS

in recent years

with Internet Explorer 8 and Firefox 2

greatly

improved accessibility efforts

as CSS2
more fully
supported layout and positioning
.

Early

software
products
specifically designed with individuals with disabilities in mind

included s
creen
readers JAWS (Job Access With Speech) for Windows

(
http://www.freedomscientific.com/products/fs/jaws
-
prod
uct
-
page.asp
)

and competitor Window
-
Eyes

(
http://www.gwmicro.com/Window
-
Eyes/
)
,
which were
both
first released in 199
5.
Two
additional

offerings in
screen reader software ar
e the open source NVDA, NonVisual Desktop
Access

(
http://www.nvda
-
project.org/
)
, al
so for Windows and first released in 2006, and Apple

s
VoiceOver

(
http://www.apple.com/accessibility/voiceover/
)
, bundled with the Apple OS
be
ginning with OS X 10.4 in 2005.

Even with modern screen reading software, it should be
noted that
visual
W
eb brows
ers are

extremely forgiving of bad code. A page that renders just
fine for a sighted user

including
one that uses

the table
-
based layout described above

can

be
completely unusable when read by a screen reader.

Web
accessibility
standards are particularl
y
an issue for librarie
s, as
library
Web

sites of
all types

tend to be home grown. Libraries
have never had
the level of resourc
es that the business
sector
devote
s

to Web development
,
which support
expert knowledge of
W
eb standards and best
practices
;
in fac
t,
m
any
early
library
sites
began

with
one

individual
a

small group
willing to
learn enough HTML to piece together a small static site with links to the cata
log and the

handful
of

licensed

databases

available at the time
.

Those licensed databases pose an a
dditional problem:
online resources created by library
-
focused vendors, generally speaking, have terrible

accessibility

track

records. A

recent study by

Jennifer

T
atomir and
Joan C.
Durrance
(
2010
)
found that 25 of 32

vendor
datab
ases reviewed

were

margin
ally inaccessible


or

inaccessible


to screen readers.

The
se

finding
s are

truly disappointing, particularly in light of the portion of
our annual budgets these tool
s

consume.

C
ommon reasons given
by web developers in both commercial and library environments
for W
eb sites and tools that

are not
standards
-
compliant include: accessible sites
are too difficult

to
achieve,
too
time
-
consuming,
or
too
expensive to create; they are boring or not engaging;

and
the target audience does not contain users with disabilities.
There also exists a misconception
that screen reader technology will catch up. While the four screen reader products mentioned
above are all under active development, it is foolish to dismis
s responsibility for writing
standards
-
compliant code.
While becoming familiar with accessibility standards and coding
techniques to achieve compliance does take an initial investment of time, coding to standards
makes sites that
are

easier to migrate
, mor
e portable, maintainable
,

and upgradeable, and

more
likely to

interoperate with other tools.

In the long run, being standards
-
compliant can actually
save time and money, as well as your institution

s reputation;
accessibility
lawsuits are costly

not
only i
n dollars, but also in terms of customer faith and loyalty, which is much harder to fix than
bad code. Further, accessible sites do not have to be boring, but should merely ensure that users
with disabilities can experience, as closely as possible, what si
ghted readers can. Finally,
planning

with an eye toward universal design

the notion that web sites designed to accessibility
standards provide better experiences for all of your visitors

ensures that when
, not if,

users

with
disabilities become

members of

your target audience, there will be no need to retrofit or redesign

existing sites and tools.

Convinced

that accessibility standards matter
? Let

s have a

quick comparative

look at
Section 508 and
WCAG 2.0
.



Section 508

The Section 508 guidelines are
commonly misunderstood to be

part of
, or aff
i
liated with,

the Americans with Disabilities Act (ADA)

of 1990. The five
t
itles of the ADA

are intended to
prevent discrimination against individuals with disabilities, including

employment procedures,
access to

public facilities and public transportation,

and telecommunications.

In 1990, the Web

was still young, and

the
ADA

did not provide any specification
s for
accessible use

of it;
however,

there have recently been high
-
profile
l
awsuits

that invoke the ADA
, no
tably against
Target Corporation and travel sites Expedia.com and Hotels.com
,
even though ADA itself

does
not deal directly with Web accessibility.
The plaintiffs in these cases stated that they could not
take advantage of the services offered by the defen
dants in the same way users without
disabilities could.

Section 508
,
oddly enough, has its beginnings
seventeen

years earlier than the ADA in

the
U
nited
S
tates

Rehabilitat
ion Act of 1973
, which sought to prevent discrimination in federal
programs against i
ndividuals with disabilities
.

S
tandards for Web design were
added in 1998
in
Section 508

s
ubpart B, §11.94.22, paragraphs a
-
p
,

and first officially published in December

2000
.


Section 508
seeks to ensure

that Federal agencies


electronic and information technology
is accessi
ble to people with disabilities,


and
federal agencies were required to comply

with the
newly published Technical Standards

beginning in June 2001.

It should be noted that the

sixteen

checkpoints shown in Fi
gure 1 are a smaller, Web
-
specific subs
et of the six Technical Standards
outlined
in
Section 508; the other standards are for

software applications and operating
systems,



telecommunications products,



video and multimedia products,



self contained,
cl
osed products,


and

desktop and portable computers.




[INSERT Figure 1:

Section 508,
s
ubpart B, §11
94.22
,

a
-
p
,
http://www.section508.gov/index.cfm?fuseAction=stdsdoc#Web
]


It has been a decade since t
he original
sixteen

checkpoints
were published, and
as

Web

technolog
y has matured
,
the checkpoints show their age.

R
ecommendations for an update were
submitted in April 2008
, and the
United States
Access Board

(founded in 1973 as a compliance
-
ensuring body)

is curre
ntly shepherding Section 508 through the
revision process.

Information
about the

5
08 Refresh
,


including the ability to sign up for email notifications

during the
revision process
,

is available on their
Web

site
,
http://www.access
-
board.gov/508.htm
.


The United States is
not

the only country with web
accessibility legislation
; Australia, the
United Kingdom, and Ireland have all enacted laws that make it illegal to discriminate against
users with disabilities
, including in web design
.

Further
more
, Canada,
Japan,
the Philippine
s,
Spain, Sweden,
and the United Kingdom

have

all

adopted specific accessibility guidelines.

In
Canda, Japan, and Spain, these guidelines are based on the Web Content Accessibility
Guidlelines (WCAG).

In the U.S
,
each of the fifty s
tates has adopted either

policy or legislation
addressing accessibility on the state government level.

In some cases, such as the state of
California, this was an outright adoption of Section 508 at the state level
, simply codifying the
federal standards into state law
.



The W3C

and
WCAG


The W
orld Wide Web Consortium (W3C)
was
founded by Tim Berners
-
Lee in 1994
,
after
his departure from CERN
,

with the aim of standardizing
the
versions
of
HTML being used
across the
Web
. While the W3C

s original home was at the Massachusetts
Institute of
Technology (MIT),

there are now
offices

on every inhabited continent
, thus making it
international in scope
.

There are now 30 W3C standards, including CSS, SOAP, XHTML, XML,
and XSLT
, to name but a few
.

This highlights an additional difference

between Section 508 and

WCAG: the W3C develops
standards

of all kinds

for the
Web
, not just accessibility
-
focu
sed
standards. Also

u
nlike Section 508, which
requires

compliance for federal a
gencies
,
a
dherence to
WCAG
is completely voluntary.


The W3C firs
t released and recommended WCAG version 1.0 in 1999.
Like the current
Section 508, the
first set of
guidelines
was
a relatively simple checklist

(See Figure 2)
.

As with
the Section 508 checklist, the WCAG 1.0 gu
idelines
ha
ve

aged as the Web has matured
, so
WCAG version
2.0

was dramatically revised and

released

in

2008
. The WCAG 2.0 guidelines

re
struct
u
red

the

simple
l
ist of
fourteen

guidelines

into a much more in
-
depth

outline of four

principles
, the acronym for which is POUR:
perceivable,
operable,

und
erstandable, and robust

(See Figure 3
)
.

Much additional

supporting

informa
tion was added, including links to tips for

How to Meet


and

Understanding


each part of each guideline.

While this restructuring
attempts to provide

an entire
conceptual
framework

for understanding accessibility standards and
issues,

it met with criticism from d
evelopers that it had become

bloated,
unreadable
,

and vague
.

Le
d by Joe Clark, a group of developers not affiliated with the W3C created WCAG Samurai, a
revision of WCAG 1.0

that they believed to be a sufficient update.


[INSERT Figure 2: WCAG 1.0 Guidelines,
http://www.w3.org/TR/WAI
-
WEBCONTENT/
]


[INSERT
Figure 3: WCAG 2.0 Guidelines, http://www.w3.org/TR/WCAG20/
]


Another aspect of accessibility evaluation t
hat Section 508
does not address

is

levels


of
accessibility

compliance
.
Version 1.0 of WCAG contained

three
p
riority levels
, designated
simply as 1, 2 and 3
, and while there were only fourteen

guidelines, each guideline had
individual checkpoints associated with it. The

checkpoints were designated as
p
riority 1, 2, or, 3.
WCAG

used the words

must,



should,


and

may,


with reference to each priority level.

For
example, in order for a site to be accessible for
p
riority 1,

a web developer must satisfy this
checkpoint
;


for

p
riority
2
,

developers


should


satisfy
the checkpoint

for increased
accessibility
; and for
p
riority 3
,

developers


must


satisfy the checkpoint
for optimal
accessibility
. If all
p
riority 1 checkpoints were satisfied, a site could be said to have achieved

Conformance Level A;


if all
p
riority 2 checkpoints were satisfied,

Conformance Level AA


was achieved, and if all
p
riority 3 checkpoints were satisfied,

Conformance Level AAA


was
achieved. WCAG 2.0 simplified this by simply doing away with priorities

and l
abels

the
individual checkpoints A, AA, or
AAA
. AAA

can be almost impossible to achieve.

W
hat do these checkpoints and guidelines mean for libraries? While a thorough explicat
ion
of the standards is obviously beyond the scope of an introductory column, here are some
highlights for library Web
professionals
to be wary of, w
ith reference to the corresponding

508
checkpoint
s

and WCAG

2.0

guideline
s
. More information, including tec
hniques for compliance,
are available under the corresponding

WCAG guidelines at
http://www.w3.org/TR/WCAG20/
.



Tutorials, podcasts, videos, and other audiovisual content have become popular modes of
instruction in libr
aries. Transcripts or captions

that co
nvey the content as accurately as
possible

for blind and deaf users

should be provided.
YouTube supports attaching a
transcript to video, and tutorial tools Camtasia and Captivate support captioning.

o

Section 508:

checkpoint b

o

WCAG 2.0:

guideline
1.
1,
1.2



L
ibrary sites often have extensive navigation to a great deal of content

guides, m
aps,
service/department

information, etc
.

This can result in a sit
e navigation packed with as
many

as
30

links

organized

into four or five main headings. Some method of

skip
navigation


should be used to prevent a user with a screen reader from

having to endure
hearing this entire list of links read every time a page on the site containing that
navigation is loaded.

o

Section 508:

checkpoint o

o

WCAG 2.0:

guideline
3.2.3



Technical
ly speaking, all search boxes are HTML forms. Many libraries are using
metasearch tools such as federated searching, next
-
gen
eration

catalogs, and discovery
layer products. Ensure that any code used for a

single
-
search


experience, whether
developed in
-
ho
use or provided by a vendor, follows best practices for coding forms. A
broken search form on a library home page renders the most important part of the site
useless for users with disabilities.

o

Section 508: checkpoint

n

o

WCAG 2.0: guideline

1.3.1,
3.3.2



Timeouts are occasionally set on library
Web

pages or OPAC
s

that cause the browser
to
refresh
back to the home page
after a certain length of time.

While this

may provide a
pretty, uniform bank of public computers,
these timeouts are detrimental to users w
ho
require longer periods of time to scan and read content on
Web

pages.

o

Section 508: checkpoint

p

o

WCAG 2.0: guideline

2.2

Wh
ile becoming acquainted with the nuances of
Section 508 and the WCAG

require
s

some initial
time and effort,
we owe it to our patron
s with disabilities to educate ourselves, and
the vendors who support us,
about

accessibility issues.
Hopefully this first
All Access

column has
been a helpful introduction or refresher to Web accessibility standards

and has left you wanting
to

learn more!

Futur
e column topics

will

include: optimiz
ing library vendor resources for
accessibility; a comparison of screen reader software; training library staff on accessibility
issues; and mobile accessibility.
Additional t
opic suggestions are welcome; please fo
rward them
to nina.mchale@ucdenver.edu.


References

American Foundation for the Blind. 2011.

Statistical Snapshots.


Accessed February 2, 2011



http://www.afb.org/Section.asp?SectionID=15
.

Clark, Joe. 2006.

To Hell with WCAG 2.0.


Accessed February 2, 2
011.
http://www.alistapart.com/articles/tohellwithwcag2
.

Tatomir, Jennifer, and Joan C. Durrance. 2010.

Overcoming the Information Gap:
Measuring
the
Accessibility of Library Databases to Adaptive Technology Users.


Library Hi Tech

28

(4): 577
-
94.

United
States Department of Justice.

ADA Home Page.


Accessed February 2, 2011.
http://www.ada.gov/
.

United States Government.

Section 508 Standards Guide
.


Accessed February 2, 2011.
http://www.section508.gov/index.cfm?fuseAction=stdsdoc
.

World Health Organization. 2006.

Blindness and Visual Impairment Fact Sheet
.


Accessed
February 2, 2011.
http://www.who.int/features/factfiles/vision/01_en.html
.

World Wide Web Consortium.

1999.


Web Content Accessibility Guidelines 1.0.


Accessed
Februar
y 2, 2011.
http://www.w3.org/TR/WAI
-
WEBCONTENT/
.

———
.
2008.

Web Content Accessibility Guidelines 2.0.


Accessed February 2, 2011.
http://www.w3.org/TR/WCAG20/
.

This is a preprint of an article submitted for consideration in the Journal of Web Librariansh
ip
2011, copyright Taylor & Francis; Journal of Web Librarianship is available online at:

http://www.informaworld.com/smpp/WJWL