BLIND-DEV Archives

Development of Adaptive Hardware & Software for the Blind/VI

BLIND-DEV@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:
Kelly Ford <[log in to unmask]>
Reply To:
Kelly Ford <[log in to unmask]>
Date:
Wed, 18 Jun 1997 03:16:58 -0700
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (69 lines)
Hi All,

I am in agreement that some sort of expanded volunteer group is necessary
to assist in making the web more accessible.  Actually it would be nice of
some funding came forth to pay folks to work on these issues and hunt down
and educate web content developers but that's a topic for another post.

My first question is how do you define an accessible web page?  Depending
on browser, screen reader and experience, what someone considers
accessible can be all over the map.

I think most would agree that Lynx is probably the first choice in terms
of an accessible web browser for people that are blind.  Yet frames,
because they expect you to view the contents of all frames at the same
time, can be an adventure in tedium at times with this browser.  These
same sites when accessed with a browser like Netscape or Internet Explorer
and a quality Windows screen reader pose little problem.  In this latter
case one need only turn on the review cursor and mouse click on the
appropriate text, which is sometimes a perfectly effective browsing
strategy.  So is a frames-based web site accessible or inaccessible?

Client-side imagemaps have been touted as a solution to accessibility.
They offer the advantage of providing a list of browsable URLs to the
underlying links from the image being mapped.  Assuming the URLs are
somewhat obvious (see http://www.safeway.com and create a shopping list
for a case where they are not) one might say that using client-side
imagemaps is an effective technique for accessibility.

However, if you access a site that employs client-side imagemaps with a
graphical browser it is another story.  Unless the image has an alt-tag
you don't know it exists.  Even if it does have an alt-tag there's no
Lynx-like equivalent of browsing the list of underlying URLs short of
tabbing through a list of URLs.  Some might say this is all that's needed
but each time I'm forced to press tab eight times to move through an
imagemap at the top of a page I'm reminded of the orientation and mobility
technique known as shore lining, whereby the cane or dog user maintains
strict contact with some sort of edge to locate a landmark of interest.
For those who don't routinely use either mobility method, I assure you
shore lining is only used for short periods of time, perhaps to locate a
particular door on a building or an intersecting sidewalk that has no
other means of being located.  So are client-side imagemaps a good or bad
thing for accessibility?

In these two cases, I would say that browser changes, not web design hold
the keys for a solution.  First in the case of frames it would be nice if
Lynx had a mode whereby the contents of all frames being referenced from a
given page, not just pointers to the individual frames, would be
displayed.  In the case of client-side imagemaps and graphical browsers
like Netscape and Internet Explorer, it would be nice if there were an
option to allow the user to click on alt-text of an image, assuming it was
provided, and get a list of underlying URLs or additional alt-text, which
can be provided for in the HTML of a client-side imagemap.  I'd go further
and suggest that Netscape, Internet Explorer and other graphical browsers
should have a mode whereby default words like [link] would be inserted
into the page for untagged images.  This would at least let folks who are
browsing with image loading turned off and who are blind that there are
links to watch for on the page and might help us understand why pressing
tab a dozen times doesn't seem to yield much but endless URLs on the
status line.  See http://www.divein.com for an example.

I may have my dreams of features to be added to web browsers but such
changes take a long time and belief by the developers responsible that
such features are warranted.  So I ask how definitions of an accessible
page might handle these sitions now and in the future?

Kelly Ford
[log in to unmask]
See my home page at http://www.teleport.com/~kford/index.html

ATOM RSS1 RSS2