[accesscomp] An article presented to us from larry Lumpkin

  • From: "Robert Acosta" <boacosta@xxxxxxxxxxx>
  • To: "tektalk discussion" <tektalkdiscussion@xxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 24 Mar 2014 20:34:56 -0700



Hi Bob.  I know this is a long article but I recommend it.  I am used to
using the web with the facilities of JAWS to navigate web pages so am a
little biased against this approach but it may have merit.  I'll paste the
article below and also provide an attachment in case you want to save it for



Blind people and the World Wide Web


Alasdair King, Gareth Evans, Paul Blenkhorn, UMIST, Manchester, UK. Links
may be different from the original 2004 article.


1 Blind people and the World Wide Web


Perhaps you've read a book recently?  Perhaps when you finished you picked
up a newspaper and got the sports headlines, or went online and surfed some

travel sites to book next year's summer holiday?  Your local newsstand
easily has a hundred newspapers and magazines.  If you have web access, you

billions of sites available to you.  Unless, of course, you're blind, when
accessing printed or net resources suddenly becomes a very different


Traditionally, blind people have had only limited means of accessing printed
material.  Braille is the most famous access method, but only a tiny

of blind people can read Braille - some 2% in the UK.  Recent years have
seen the wider adoption of audio recordings, but like Braille these suffer

a lack of immediacy - you want the news today, not to wait a week for it to
be translated - and a blind user is usually reliant on sighted people, often

volunteers, to produce the material.  This reliance and the higher costs of
producing alternative format materials such as audiotapes necessarily reduce

the material available.  This is a poor comparison with what is available to
sighted users and their choice of material.


The rise of affordable personal computing in general and the Internet in
particular promised an incredible improvement in access to written

With a personal computer, some easily-available technology, and a web
browser, you are no longer restricted to tapes sent through the post or the

technology of the radio: you now have access to billions of web pages,
personal, corporate, educational, entertaining, all available from your
home.  And

there is no better time for this huge revolution: the great majority of
blind people in developed countries become so because of the effects of age.

average life expectancies increasing the number of potential blind Internet
users grows and grows.  There are some one million registered

people in the UK, of whom 750,000 are over 75.  They want access to the same
material they've always had, whether it's the London Times or the National

Enquirer, but the material may not be available in an alternative format.
Relying on what other people choose to translate for your benefit reduces

choice and freedom.  Besides, sighted people have taken to the Internet in
their millions for booking holidays, researching family trees and countless

other uses: blind people need the same opportunities, and the technology
makes it possible.


This is not to say, alas, that the web is a happy land where a blind person
can surf and browse with all the freedom and ease of a sighted person.  To

understand why, we need to examine how blind people access computers in the
first place.


2 How blind people access computers


The last decade has seen the triumph of the rich graphical desktop, replete
with colourful icons, controls and buttons all around the screen, controlled

by the mouse pointer moving about the screen clicking and dragging.  This is
not, on the face of it, a usable environment for blind people, but use it

they must.


Many people with a significant visual impairment have some degree of
residual vision.  There are assistive technology solutions for them: a
screen magnifier

application, such as 

ZoomText from Ai Squared,

magnifies a small area of the display, potentially filling the entire
computer screen.  The user can move the area being magnified around the

This allows the user to control the computer interface directly, and is a
good solution for people with gradually-degrading vision, especially those

are already familiar with their computer interface but are starting to have
trouble seeing it.  However, for those with a significant visual impairment

or complete blindness, there are different two options.


The first is to use a screen reader.  This is an application that attempts
to describe to the blind user in speech what the graphical user interface is

displaying.  It turns the visual output of the standard user interface into
a format that is accessible to a blind user.  In practice this means driving

a Braille output device - a row of Braille cells with mechanical pins that
pop up and simulate Braille characters under the user's fingers - or, more

a text-to-speech synthesizer.  We will deal exclusively with these
text-to-speech users in the rest of this article because they form the great

of users, actual and potential.  The screen reader acts almost as a sighted
companion to the blind user, reading out what is happening on the screen -

popup boxes, command buttons, menu items, and text.  Ultimately screen
readers have to access the raw video output from the operating system to the

and analysing it for information that should be presented to the user.  This
is a complex process, as you would expect from an application that is

to communicate the complicated graphical user interface in a wholly
non-visual way.  There are many screen readers available, including JAWS
from Freedom

Scientific, Window Eyes from GW Micro, or 

Thunder from Screenreader.net.

If you have Windows 2000 or XP, you'll find that Microsoft have included a
basic screen reader in the operating system, called Narrator: try activating

it, opening Notepad and typing some text or checking your email without
looking at your screen.


The goal of a screen reader is to make it appear to the user as if the
current application was itself a talking application designed specifically
for blind

users.  This is difficult to accomplish.  Applications often have particular
user controls or methods of operation that must be supported by the screen

reader.  For example, a spreadsheet program operates very differently from
an email client.  This forces screen reader developers to adapt their

to support specific applications, typically the market leaders like
Microsoft Word.  It also means that applications that utilise simple
interface components

like menus and text boxes will work best with screen readers.  Those with
non-standard interface components like 3D animations may be difficult for a

reader to access.


The second way for a blind person to use a computer is to take advantage of
self-voicing applications.  These are usually applications written

for blind people that provide their output through synthesised or recorded
speech.  The obvious advantage is that the application designer can ensure

what is communicated to the user is exactly what the designer wants
communicated - although this assumes that the designer's conception of what
the user

needs or wants to hear is correct!  Aside from the extra design and
development required to produce a self-voicing application, the main
drawback is that

the application cannot be used at the same time as the user's screen reader.
If the application usurps the screen reader, the user's customary interface

to the computer, it takes upon itself the responsibility for being at least
as comfortable and usable for the user as their screen reader.  Users become

accustomed to their particular screen reader and its operation and will have
it configured just as they want it.  The hotkeys of a self-voicing

may be different; the voice may be different, and have different
characteristics.  For example, many screen reader users set them to read out
as fast as

possible, which sounds odd if you have never heard it before but makes sense
if you are accustomed to it.  With a self-voicing application, the user may

even have to switch off their screen reader, which is most undesirable if
they want to use another non-self-voicing application at the same time.


Whether using a screen reader or a self-voicing application, the use of the
sense of hearing rather than vision has great implications for the design of

the interface.  The visual sense, or visual modality, has an enormous
capacity for communicating information quickly and easily.  If you look at
an application

on your computer display and you will immediately notice the menus, icons,
buttons and other interface controls arrayed about screen.  Each represents

a function that is available to you, and a quick glance allows you to locate
the function you want and immediately activate it with the mouse.  Say the

application is a word processor: you can go straight from reading the text
of your document to any one of the functions offered by the interface.  Now

imagine that to find the print function you will have to start at the top
left-hand corner of the screen and go through each control in turn, wait

its function is described to you, until you find the function you require.
Of course, experience blind computer users will not rely on navigating

menus for every function.  They will utilise shortcut keys, such as "CTRL-P"
to print a document, develop combinations of keystrokes to complete their

most common tasks, and learn the location of commonly-used functions in
menus and applications.  This requires, however, a consistent user
interface, where

shortcut keys and keystroke combinations can be relied upon to perform the
same function each time and menu items are always located in the same place.


The important constraint on the use of computers by blind users is that they
rely on hearing, rather than sight.  Why is this such a problem?  First,

users are constrained into examining one thing at a time in an order not of
their own making - they do not know the structure of things before they

them.  This is the problem with unfamiliar, rich, new interfaces.  Second,
blind users have to listen to a surprising amount of text to give them the

amount of information as a sighted user might be able to gain in a quick
glance.  Sighted users might be able to glance through a large document,

the chapter and paragraph headings for a key word or phrase, because they
can see the headings instantly distinct from the body text and what words

contain.  A blind user, even if they can jump from heading to heading, has
to wait for the slower screen reader to speak the heading: setting it to

as fast as possible might seem more sensible now.


These two constraints, fixed order of access and time to obtain information,
mean that interfaces that rely on hearing must comply with a principle of

maximum output in minimum speech.  This greatly changes usability:
superfluous information is not just a distraction, as a page with lots of
links might

be for a sighted user, but a real barrier to using the interface.  Blind
users must not be asked to use a complex interface with many options.  If a

misses some output, it will need to be read out again, so an explicit way to
repeat things is required.  Most importantly, users need control over what

is being said: sighted users can move their gaze wherever they want whenever
they want, and blind users need some similar control of the focus.  Imagine

reading something where you can only see one word at a time with no way to
go back or forwards.  Non-visual interfaces need to provide means to

through the document, stop, go back, skip items, repeat and explore the text
available.  This affects how blind people browse web pages, as we will find

out next.


3 Access to the web


So, knowing some of the problems that blind people have with accessing
computers in general, how can they access the wonders of the World Wide Web
in particular?

What are the particular characteristics of browsers and more especially web
pages themselves? 


Websites vary enormously, but with a quick browse around the most popular
sites you will quickly notice a common characteristic: a very heavily visual

graphical interface:  images, including animated advertising banners;
non-linear page layouts, like a newspaper front page with items and indices

around the screen; navigation menus and input controls for search functions
and user input.  And these are simple static items: advanced sites now take

advantage of dynamic web page features like whole user interfaces written in
Flash.  For every Google, applauded for a simple and accessible user

there is another website with tabs, buttons, pop-ups and other great
features for sighted users. 


It is important to realise that not only are web pages full of rich
features, but that their arrangement in the pages are completely
non-standard.  We

have described how blind users can use complex graphical applications by the
use of hotkeys and learning the user interface.  This required a consistent

user interface.  Surf about some more websites, and you will realise quickly
that no such consistent user interface exists for web pages.  In face, a

web page can be as rich a user interface as a standalone application.
Imagine arriving at an online bookshop's website, with all those images,

titles and text paragraphs, and having to start at the top left-hand corner
and progress one item at a time through the page to find the login to check

your last order.  No shortcut keys are available for useful functions like
"search this website" or "contact the website owner" that might be available

on the page.  Every website has a different user interface which must be
explored and understood to use it, which places great demands on blind users

make the necessary effort.  So, how does a blind user start to get to grips
with these pages? 


The immediate response might be to use the user's screen reader to access a
conventional browser like Internet Explorer.  This has problems: we know

each application makes different demands on the screen reader, and the
heavily-visual and non-standard interfaces of web pages pose considerable

to a screen reader.   Navigating the web can be compared to trying to use
the largest and most complex application that a blind person will ever

A specific problem with Internet Explorer is that the need to allow the user
to move around the document we have described is complicated by the lack

of a caret on a web page, an indicator of the position at which you will
enter or delete text usually shown as a flashing vertical bar in a text

Sighted users can simply glance at a different area to change their focus,
but screen reader users need to move the focus of the screen reader to the

area of interest, and this is normally done by moving the caret.  Browser
windows, however, do not have carets - you can only scroll the whole page up

and down and look for the text of interest.  The only items you can select
individually are links or form items.  A screen reader could simply choose

read a web page displayed in Internet Explorer from the very top of the page
to the bottom, but this would be immensely time-consuming for the user.

and frames and forms further complicate a web page.  This is not to say that
using a screen reader is impossible: advanced screen readers do provide

navigation modes for web pages with a great deal of success. After all, web
browsing is one of the common applications which a screen reader developer

will try to support.  However, complex navigation mechanisms are the result,
and whilst these are excellent for experienced and highly skilled users,

are not necessarily ideal for the newly blind user who may be coming to the
technology late in life.  Web access is a general, not specialist need, and

needs to support a general, no n-specialist group of users. 


So, why not write a self-voicing web browser?  Some have been developed,
such as the IBM Homepage Reader.  They can be geared to the needs of the

group, although the general problems with self-voicing applications
described above apply.  The developer, even if they could re-use existing
browser and

parser technology, has to design a complex new interface for the complex
graphical web pages to be browsed.  Users will usually have a screen reader

why make them learn to use a new application, rather than further develop
and utilise their existing screen reader skills?  Web pages are complex

and vary in their own interfaces: can we keep the user in familiar territory
at least in trying to navigate through these rich structures? 


One alternative solution that we propose is to translate the web page
content into a 'screen reader-friendly' format.  To do this we take a normal

web page and strip out superfluous information like decorative images or
table-based visual formatting to produce a simpler navigable document that

in accord with the principle of maximum output in minimum speech we
established earlier.  We can give the user a cursor and let them loose in
the translated

document, so they have control over what is being read out and they can
explore the document on their own terms.   The user interface is simplified.

user can use their familiar, trusted screen reader, so the necessary
learning curve for getting used to browsing the web through this interface

be less steep.  A number of applications based on this theory have been
developed, including Franck Audio Data's WebFormator and the Baum Web

Our version is called WebbIE.


4 WebbIE


WebbIE re-presents the information from a web page in an accessible format
suitable for a screen reader - a panel of plain text (see Figure 1).  We did

not want to build a browser, so we utilised the Microsoft WebBrowser object,
which gives a program its own internal Internet Explorer.  This can fetch

a web page and parse it into a standard World-Wide-Web Consortium (W3C)
document format, which can then be queried by WebbIE for information on the

page.  This takes care of the back-end processing and leaves us free to work
on the user interface.  Since IE is so widespread a browser, we can expect

almost every page to support it, which means that we do not have to worry
about unsupported web page features.  The drawback is that the application

only work on Windows machines with Internet Explorer 5 or higher, but this
includes a very significant number of machines.


Of course, we still have to decide what to do with the web page features
that have been parsed and provided to us.  We use the WebBrowser to obtain

on the links and forms on the page, since they are vital for navigation and
use (for example search engines, commerce sites, or database queries).  All

types of HTML link are supported, including images and image maps.  We then
obtain the HTML for the body of the page from the WebBrowser and parse it

generating a text-only document more like a plain text file than a web page.
This allows us to discard images and redundant mark-up, like tables used

for visual formatting, while still communicating important structural
mark-up characteristics like headers or lists, mostly by using simple new
lines for

new paragraphs, headings or list items. Following the principle of maximum
output in minimum speech, the user can choose what non-text content is

so they can either have image descriptions provided to them or discarded.  .
The output is plain text, which can be moved around or searched like a text

document but retains its vital HTML functionality with forms and links (see
Figure 1).


Screenshot of Internet Explorer at Amazon.co.uk's website - lots of links,
images, buttons, et cetera.


Screenshot of WebbIE's display of the same Amazon.co.uk website - plain
text, links in a list.


Figure 1: WebbIE in action at Amazon, showing the original website and
WebbIE's presentation of it.  Note the links (LINK) and the form elements



Additional navigation features are provided to let the user move a caret
around the text, allowing the user to control what their screen reader reads

them.  For example, the user can skip over any links to the next piece of
text, which comes in useful for those pages that use navigation bars at the

of the page.  Filling in forms is done within WebbIE: the user moves the
cursor to a form item and hits return.  They complete a simple text box and

page is updated with the input for review.


When the user initiates an action that results in an exit from the page,
such as clicking on a link to another web page or hitting the submit button

a form, the action is passed back to the WebBrowser object, which processes
it as a normal user-generated event and gets the new web page or submits the

form depending on the event.  WebbIE is updated with the result returned
from the website.  The user therefore enjoys a fully-functional text-only



Better still, if plug-ins or support applications are installed, the
WebBrowser will trigger their action automatically when their content type
is encountered,

which means that you can access things like streaming audio from news or
radio sites.  You can bring up the native Internet Explorer window visible

you want to access the web page directly - for example, to access JavaScript
controls or Java applets.  The IE favorites are available to use and amend.

It also supports secure access to web pages (the SSL protocol), so a blind
user can shop safely.


We mentioned that many visually impaired people have some functional vision,
and that they can benefit from magnification technology.  WebbIE does

some support for these users by allowing them to increase the font size of
the text and change (invert) the colours, but it does not magnify images, so

it is not a magnification program per se.  Users might find the simpler
WebbIE interface to web pages easier to use than scrolling around a
magnified but

still very complex graphical web page.


5 Problems that WebbIE faces


The problems that WebbIE encounters with some web pages are interesting
because illustrate problems that any non-visual web browser will encounter.

can be divided into three sets of problems: how to present web pages to
users; poor use of HTML; and inaccessible content.


Presenting web pages to users


The principle of maximum output in minimum speech demands that we decide
which mark-up features of HTML are communicated to the user and how they can

be presented.  To give an example, HTML defines bulleted lists of items: do
we need to communicate to the user that this is a bulleted list, by adding

to the text something like "Bullet item:" at the beginning of each line, or
do we simply provide a new line?  There are six types of heading in HTML,

displayed with different fonts and sizes in text: does the user need to know
the type of their current heading?  Is it more important that the structural

features of the web page are communicated to the user, or is it better that
the user can work through the web page as quickly as possible to find what

they want?  With WebbIE we have generally gone with the latter approach, so
the majority of mark-up features - headings, paragraph breaks or lists for

example - are simply presented with new lines. An interesting related
problem concerns items that are useful for sighted users, such as navigation

at the top of each page, but undesirable for blind users, who then are faced
with a long list of the links at the top of each page (some sites may have

more than 50 such links).  WebbIE allows users to skip to the first non-link
line, but a more elegant solution might be the mark-up of the navigation bar

as a navigation feature that can be skipped unless requested specifically.
The W3C provides a mechanism for this in HTML, but few website designers

advantage of it.  In general the problem of how to squeeze the output of a
rich visual medium through a more restrictive speech-based interface

compromises and design decisions with no "right" answer.  Testing with
real-life users is the best solution.


Poor use of HTML


There are three main problems with poor use of HTML, and they are all
preventable.  The first is especially simple.  Images are useless to blind

but HTML allows for a text description to be applied to an image, called an
ALT tag.  Most images can be discarded when a web page is presented in

but images that are used as links must be somehow communicated to the user
to inform them where a link will take them.   Adding the ALT tag to the link

image allows WebbIE to provide useful information to the user, for example.
"Link to catalog".  Without the tag the only information that can be

is the destination URL of the link.  More and more sites use server-side
processing to produce dynamic pages, which can lead a list of identical

to a web page called something like "script.pl?username=Alasdair".   This is
most disheartening for a blind user, who will have to find the content they

want by trial and error or give up on the site completely.  The next two
problems are more annoyances than show-stoppers.  Frames and the use of

to provide visual structure can be worked around by WebbIE, but can produce
disjointed content when presented to the user solely as text.  For example,

HTML always describes tables from left to right, row by row.  If a designer
has intended the layout of items in a table to have a semantic meaning for

visual users, for example putting links in one row and descriptions of the
links in the row below, they will look attractively lined up for sighted

but a blind user will meet all the links and then all the descriptions with
no obvious connection between them.  Frames require WebbIE to go and get the

frame content separately, and often produce a long list of internal
navigation links at the top of every page, but these problems are generally

More difficult are a few websites that seek to prevent users from accessing
frame content directly, and use JavaScript to forcibly reinstate the frames

- WebbIE cannot get at the content within the frames, and the user is left
with nothing but a description of the frames.


Inaccessible content


The HTML coding problems might be resolved with more attention to
accessibility by web designers, but experience suggests that this is
optimistic.  We

will therefore continue to develop WebbIE to handle problematic HTML code.
However, the third type of access problem is more fundamental.  HTML is

a text-based format designed for the presentation of text documents.  This
is perfect for blind users but not for website designers, who have turned to

many alternative technologies to provide active functions to their pages and
achieve the desired visual effects.  These technologies include Adobe

files, Java applets, and most recently entire websites presented entirely in
Shockwave Flash.  Strategies for coping with these largely depend on the

to which the companies behind these proprietary formats have worked to make
them accessible to screen readers.  WebbIE users can switch to the Internet

Explorer view and access the content if their screen reader can access the
format.  Embedded objects like Java applets have ALT tags like images, but

does not allow access to the content.  (Though since many applets simply
provide animation or other visual effects to an image that may be

A more subtle problem is the use of JavaScript in pages where it replaces
the functions normally reserved for HTML, such as submitting forms or

to another web page.  For example, if a designer uses the JavaScript onClick
command to create a link rather than the normal HTML tag WebbIE will have

great difficulty in identifying and following the link.  An accessible
interface to the JavaScript functions of a web page would be possible to

but whether it would be desirable or even usable by blind users is another
matter.  New technologies are introduced to the web all the time: all we can

ask is that accessibility issues are addressed by their developers.


Alasdair King, February 2004. Last updated June 2008.


Robert Acosta, President

Helping Hands for the Blind

(818) 998-0044



Other related posts:

  • » [accesscomp] An article presented to us from larry Lumpkin - Robert Acosta