VICUG-L Archives

Visually Impaired Computer Users' Group List

VICUG-L@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Gregory J. Rosmaita" <[log in to unmask]>
Reply To:
Gregory J. Rosmaita
Date:
Thu, 16 Sep 1999 14:19:30 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (219 lines)
aloha damon!

i recently received a similar request:

quote
I am a web designer and I would be particularly interested in learning how to
ensure that websites are accessable for all, especially those who are blind or
have visual  imparement. I wonder if you have information which you can send
me, or links  which I might learn from?
unquote

my reply follows:

--- BEGIN POINTERS TO RESOURCES FOR ENSURING ACCESS TO THE BLIND/VI ---
thank you for contacting me to inquire about resources that will enable you to
design web sites that will be accessible to the blind and visually impaired...
as a totally blind individual who, for the past 3 and a half years, has earned
his daily bread designing, constructing, reconstructing, and maintaining web
sites (many of which have nothing to do with blindness or vision loss), i
applaud your desire to ensure that the pages that you create are universally
accessible...

i'm going to list a few essential resources first, and follow them up with a
quick list of "accessibility essentials"...

1) the best place to start your inquiry is at the W3C's Web Accessibility
Initiative's web space...  as you may know, the W3C (a.k.a. the World Wide Web
Consortium), is the international industry-based consortium which has developed
(and continues to develop) many (if not most) of the mark-up languages used on
the web today...  in 1997, the W3C launched the Web Accessibility Initiative
(WAI), which is charged with ensuring that all of the recommendations
(W3C-speak for specifications) issued by the W3C address accessibility
concerns, as well as drafting guidelines for developers of web content (a.k.a.
page authors), developers of authoring tools, and developers of user agents
(a.k.a. browsers)

the WAI's home page is located at:
        http://www.w3.org/wai/
the WAI References list is located at:
        http://www.w3.org/wai/references/

the Web Content Accessibility Guidelines (WCAG), which detail how to build
accessible pages, are located at:
        http://www.w3.org/TR/wai-webcontent/
a checklist for WCAG can be found at:
        http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist
and a "Techniques" document, which contains implemention strategies for WCAG,
can be found at:
        http://www.w3.org/TR/1999/WAI-WEBCONTENT-TECHS-19990505/

note that WCAG is a "W3C Recommendation", which means that it caries the same
weight and authority as the HTML or Cascading Style Sheet mark-up languages, as
well as all the other Technical Reports generated by the W3C...

while many of the people involved with the WAI work for consortium members or
the W3C itself, one of the unique things about the WAI is that it has extended
invitations to experts in various fields relating to technology, the internet,
and access to information from every disability group, as well as the
manufacturers of adaptive equipment, and those interested in assuring access to
information, to participate in its working groups...

there is also one portion of the WAI which is open to the general public -- the
WAI IG, or Web Accessibility Initiative Interest Group, information about which
can be found at:
        http://www.w3.org/WAI/IG/

the WAI-IG also sponsors a general-interest emailing list, which is open to the
public, where news of web accessibility -- in both theory and practice -- is
exchanged...  you can find out more about the WAI-IG list at:
        http://www.w3.org/WAI/IG/Overview.html#Uselist

you can peruse past posts to the list (as well as monitor the list, without
subscribing) by accessing the emailing list's hypertext archive, which is
located at:
        http://lists.w3.org/Archives/Public/w3c-wai-ig/

2) the HTML Writers' Guild (HWG) offers on-line courses on accessible design --
you can find out more about these courses from the HWG's Accessible Web
Authoring Resources and Education (AWARE) Center, which is located at:
        http://aware.hwg.org/

3) the Center for Applied Special Technology (CAST) offers a service called
BOBBY, which will check your pages for accessibility errors......  you can
either check your work page-by-page using the web-based interface, located at:
        http://www.cast.org/bobby/
or      http://www.cast.org/bobby/advanced (to take advantage of BOBBY's
advanced options)

you can also download an offline version of BOBBY, which allows you to analyze
an entire site or folder/directory at one go, by using the following URL:
        http://www.cast.org/bobby/download.cfm

4) validate your HTML / XHTML / XML / CSS -- the first step towards accessible
markup is valid markup, and you can use the following 2 validation services,
offered by the W3C, to validate your pages' HTML and CSS online:
        HTML Validator: http://validator.w3.org/
        CSS Validation Service: http://jigsaw.w3.org/ (the CSS validator can be
downloaded)
one of the nice things about both validation services is that you can add an
auto-validation button/link to your pages, enabling you (and anyone else who
cares to do so) to check your pages on-the-fly -- a useful option, especially
if you end up working late into the night on a regular basis!  for an
illustration of the auto-validation link, check the bottom of
        <http://www.hicom.net/~oedipus/index.html>

in addition, i would strongly advise you to download and use Dave Raggett's
HTML Tidy -- one of the handiest error checking utilities i've run across --
more information about which can be found at:
        http://www.w3.org/People/Raggett/tidy/

5) here some simple things to consider when designing your pages so that they
are accessible to the blind and visually impaired:

A. use uncommon sense -- accessibility and interoperability need to be built
into a site from its inception, not added as an afterthought...

B. as your sites expand, consider the possible ramifications of any bells,
whistles, and gee-gaws you might consider adding...  many "bleeding-edge"
technologies (such as javascript, flash, etc.) are either completely
inaccessible to the blind, and/or cause blind users' adaptive equipment to
malfunction...

C. use semantically sensible hyperlink text -- many blind/VI users navigate web
pages via a list of links, so make sure that the hyperlink text you define
makes sense when read in isolation (i.e. avoid using such meaningless hyperlink
text as "click here", "here", and the like)...  well-conceived hyperlink text
should be brief, and yet convey enough information about the resource to which
it points, so as to allow the user to make an informed decision whether or not
to follow the link...  if you use MSIE 4.01 or 5, you can download the MSIE
PowerToys (for IE4x) or PowerTweaks (for IE5) using the "Product Update" menu
item (accessed via the "Help" menu in IE4 and the "Tools" menu in IE5), which
will endow you with the ability to view a list of links for the currently
rendered page when you right-mouse-click on a non-active area of the page...
and improved version of the PowerTweaks "Link List" tool (as well as a host of
other useful utilities) is available from the University of Wisconsin's TRACE
Center:
        http://trace.wisc.edu/world/web/document_access/

D: if you use a graphic as a hyperlink, make sure that you define a textual
equivalent for the image -- the ALT text for the IMG declaration should follow
the rule set out in item C of this list -- when you define a textual equivalent
for a graphical hyperlink, make sure that you are describing the _CONTENT_ of
the hyperlink's target, rather than the graphic itself...  for more detailed
information on this topic, please refer to:
        http://www.w3.org/TR/WAI-WEBCONTENT/#tech-text-equivalent

E. if you really must use frames, make sure that you include a NOFRAMES section
for those accessing the framed site with a frames-incapable browser...  the
general rule of thumb is that the NOFRAMES portion of the document source
should contain the contents of the navigation frame in either an ordered or
unordered list...  for more information about the NOFRAMES element, consult:
        http://www.w3.org/TR/WAI-WEBCONTENT/#tech-text-equivalent

and, for a convincing argument against the use of frames, please consult Jakob
Nielson's article on the usability and accessibility problems posed by the use
of frames, which is located at:
        http://www.useit.com/alertbox/9612.html

F. there are still a large number of cybernauts who, for whatever
reason--physical, financial, or philosophical--either choose to, or have no
choice but to, access the web via a text-based browser, such as Lynx or
NetTamer...  obviously, anyone accessing your pages/sites using a non-graphical
browser (which, would, of course, include anyone accessing your page using a
telephone-based browser) won't be able to perceive any of the graphics defined
for that page, which is why alternative textual equivalents (such as ALT tags
and LONGDESC) are so very important...  what isn't quite as obvious is that the
use of visual layout is also lost when anyone accesses your pages with a
text-based browser...  therefore, it is of the utmost importance that you do
not rely on visual cues alone (such as changes in font size, font color, etc.)
as a means of conveying meaning to the user...  one way to check your pages for
non-graphical usability is to either use Lynx, the text-based browser, to view
them or to view them using a Lynx Simulator...  you can:

a) find out more about Lynx using the following URL:
        http://www.hicom.net/~oedipus/weave.html
b) download a version of Lynx that runs on either Windows 9x or Windows NT
using the following URL:
        http://www.hicom.net/~oedipus/vicug/blynx32.zip
c) telnet to a publically available version of Lynx using the links located at:
        http://www.hicom.net/~oedipus/weave.html#telnet
d) use one of the Lynx Simulators, a list of which is located at:
        http://www.hicom.net/~oedipus/weave.html#sim

and, if you are so inclined, you might want to check out some of the other
non-visual/graphical browsers that are currently available -- a description of
some of these "Alternative Web Browsing" products can be found at:
        http://www.w3.org/wai/references/browsing/

G. and, finally (at least for now!), test your pages using blind and visually
impaired volunteers -- while i would be more than glad to check your handiwork
myself, there is no substitute for having as wide a range of individuals test
your pages as possible...

i hope that you find all of this useful -- if you're overwhelmed or confused,
please do not hesitate to let me know, and i shall endeavor to be less
obscure...  and, as i indicated earlier, if you would like me to take a listen
to some of your pages and offer advice/suggestions, please do not hesitate to
send me their URLs!

gregory.

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <[log in to unmask]>
   President, WebMaster, & Minister of Propaganda,
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
--------------------------------------------------------


VICUG-L is the Visually Impaired Computer User Group List.
To join or leave the list, send a message to
[log in to unmask]  In the body of the message, simply type
"subscribe vicug-l" or "unsubscribe vicug-l" without the quotations.
 VICUG-L is archived on the World Wide Web at
http://maelstrom.stjohns.edu/archives/vicug-l.html


ATOM RSS1 RSS2