E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Terence de Giere
Date: Tue, Jul 29 2003 8:22AM
Subject: RE: evaluating Web accessibility software
No previous message | No next message

Regarding screen magnification and some other issues.

I agree that making a Web page as flexible as possible so that a user's
need to use assistive technology to get the information in a page is
minimized as much as possible, but there are limits to what a single
browser and page design can do.

I have been experimenting with graphical interfaces constructed entirely
from cascading style sheets (CSS2) formatting pages coded with ISO/IEC
15445:2000 HTML. This version of HTML is a stripped down version of
HTML 4.01, and is slightly more backward compatible with older browsers
than the new XHTML versions of HTML. This version of HTML also has a
number of restrictions beyond HTML 4.01, such as not allowing images in
a page to have any HTML based sizing information, and headings (h1
through h6) may not be placed inside the <div> element. This prevents a
coder from creating many potential accessibility problems by eliminating
some kinds complex nesting of elements in HTML. ISO/IEC 15445:2000 HTML
cannot be created in most graphical HTML editors unless they have a code
only view, and do not alter code when in graphical mode, so it is almost
never used in practice. This is the only version of HTML that is an
international standard.

These experimental interfaces are aimed at W3C Triple-A compliance,
visually have a basic page header, a top row of navigation 'buttons',
and a left navigation menu, and the content scrolls while the menus
remain fixed (except in Internet Explorer which does not support this
CSS feature properly), so the page looks as if it is in frames, but is
not. No tables are used for format and all sizing is relative, so if the
user increases the font size, the whole page reflows, including the
menus, so all the components of the interface remain readable, visible,
and more or less proportionately sized. The images change size with the
text. But there are limits. Depending on the size of the monitor, an
increase in font size of about two times is the limit, three times with
a large monitor and some browsers. The interface works fine at 640x480
but is optimized for 600x800 to 1024x768 monitors and will display well
on larger monitors. With alternative style sheets that allow the page
to display as a single column, the page can be read in Opera with ten
times magnification on a 17 inch (43cm) monitor. Small screen
performance, as on a PDA is similar to magnification - we basically have
the space to display just a small portion of a page designed for a
desktop monitor.

Clearly one can do a lot to make a graphical interface more malleable
for accessibility for the visually impaired, but it is not practical to
try to accommodate every eventuality. Plain unformatted HTML is the most
flexible form, and software that can manipulate this for a user to
accommodate a particular problem offers the most potential.

Screen magnifiers perform a different function than the text size change
afforded by browsers, or the page magnification in Opera. They allow the
user to magnify other applications, say Microsoft Word, not just the
browser . MAGic, for example, provides a number of different ways the
user can enlarge the screen. It can enlarge the whole screen up to 16
times original size, or just part of it; it can magnify just the portion
centered on the mouse etc. Text can be stretched vertically about 70
percent, so for some users, with a large monitor the text can be large
enough to read without increasing the page width, reducing horizontal
scrolling, which is a big usability problem when reading text, filling
in forms and so on. There are many options beyond simple enlargement
that give users a choice that may work better for them.

MAGic also can smooth text, which enlarged this way is otherwise
pixelated, and provides text to speech aural presentation as well. For
users that do not need speech, and only need to use the Internet with a
browser, Opera does very well, and if the user knows how to set
preferences in opera and use its accessibility features, it can
duplicate and sometimes surpass many of the features of a screen
magnifier used with a browser.

All of these features of different software overlap, but in the end, it
might be personal preference that leads a particular user to use a
particular solution. Internet Explorer works well with assistive
technology that is customized for it, but Internet Explorer is currently
more limited than some other browsers standing alone by itself.

There is also the issue of cost. Screen readers and magnifiers are
expensive. While Windows has speech synthesis and magnification built
in, it is much more primitive than what a good screen reader or
magnifier can do. The lower the initial cost of the assistive technology
software, the more likely the user will need a Web page that is more
accessible than that provided by Section 508 rules, or the W3C Web
Content Accessibility Guidelines Level A compliance. It may be a user
might just want a low cost, but more sophisticated Internet browsing
solution, in which case IBM Home Page Reader or Opera might do. There is
the Simply Web 2000 Talking Browser (built over Internet Explorer),
which is free, but it is a miserable experience unless the Web page is
Triple-A compliant on the W3C accessibility scale.

As with any other product group, Web accessibility software has
intriguing and exasperating variations in capability, usability, and
affordability. We cannot create pages customized for all these
variations. We need to create page designs that in principle provide all
the content and function as a base core which allows assistive
technology to successfully process that core into a form that works for
the user, and around which we can additionally provide a good usable
graphical interface, and perhaps a few alternative interfaces, using
CSS, XSL, and/or server side technologies. We can add multimedia
equivalents of the core information, but not replace it with them.

Web accessibility checking software for evaluating whether we have been
successful also has the same maddening variations in ability to detect,
correct, and inform us of problems in web pages. In the end, personal
skill, knowledge, and the appropriate selection of tools, which might
sometimes just be based on personal preference, is all we have to do the
job. The tools are just an aid, it is how we use them, and how much we
know about what they can and cannot do that determines the quality of
the result. There are enough variations that if we wanted to
'objectively certify' that a site met a particular set of accessibility
guidelines, we would probably have to design the site to be evaluated by
that particular tool. The usability of the site might suffer as a result
of such a procedure. The required manual inspection of the page, which
usually covers about half of the accessibility issues that checking
software does not detect well, is often where major problems exist.

The main thing is to have a design philosophy that is at its core based
on accessibility, rather than a philosophy that is based on doing
business as usual and then trying to fix it with a tool after the fact.
That is, before we build the site, we knowledgeably use the tools and
our experience to create basic accessible templates for the site, which
also test well with assistive technology, and hopefully, usability tests
of the templates with a wide variety of users, disabled or not, as much
as one can do within the budget constraints of the project.

There also has to be a specific plan for training the site personnel
extending the site and maintaining it as it grows and new material is
added, so that accessibility does not deteriorate with time. I think
this is one reason why accessibility is a problem - a consultant
analyzes a site and makes recommendations for accessibility
improvements. One year or two years later, nothing seems to have changed
much because, even with the purchase of software tools, the knowledge
base for staff required to create and maintain accessibility was not
established at the same time, or not continued with changes in personnel.

Terence de Giere
= EMAIL ADDRESS REMOVED =






----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/