WebAIM - Web Accessibility In Mind

E-mail List Archives

Linear Access and Text Only

for

From: Terence de Giere
Date: Dec 4, 2003 1:26PM

ONE OR TWO SITES?
In one project I worked on, we used a content management system. This
system was not ideal for accessibility, because it tended to strip out
accessibility features of pages, and the ergonomists wanted a separate
version of the site for accessibility. The first requirement was for
linearization, and the second that the accessible version not lack
anything from the graphical version. The content management system
generated two sites from the same content. The accessible version did
not use tables, used real headings etc. The only image features made
text-only were graphical link buttons, all other images were preserved
in the accessible version with alt text and longdesc and a "D" link, and
the absence of tables assured correct linearization with all devices.
Because the two sites were generated by a content management system, the
content for the two sites was identical except for improvement in
accessibility of certain features in the accessible version; this
eliminated manual maintenance of two site, so the accessible version was
always up to date with the 'main' version. The accessible version was at
a separate URL with a manual text link from the graphical version
because screen readers could not be detected, there had to be a way for
the user to get to the accessible version site as a server-side
switching mechanism was not budgeted into the project. The developers
had enough trouble just getting the content management system running.

Even if one attempts a one site design for accessibility, one is really
developing multiple interfaces in that one site, like a Swiss Army knife
encapsulates multiple tools in a single device. In one sense, a split
site design simplifies the situation because the problems of concocting
an accessible site within a graphical design can be avoided, but the
need to understand and implement accessibility properly is still the
same. A content management system is expensive, may be difficult to set
up, and is inflexible. Managing two sites without a content management
system is difficult. Users really don't want two sites either, when they
get to a site they just want it to work.

IMAGES ARE NECESSARY.
Before development stopped on the pwWebSpeak audio browser, which had a
text-only low vision display, one of the most requested features from
users was that it also display images. Clearly a text-only accessible
site lacking images does not serve the full community of disabled users.
Text-only works only for those who cannot see any image at all, either
through blindness or through technology, such as a text-only browser. As
Paul Bohman pointed out some posts ago, some users may need to rely on
images more than others, so the need for images does not go away for
many kinds of visual impairments short of total blindness, and in fact
there are ongoing attempts to make images a tactile experience for blind
users.

GRAPHICAL DESIGN AND LINEARIZATION.
Designers and developers tend to focus on the 2-D graphical design, and
then try to figure out how to make it accessible afterward. For
accessibility it seems to make sense to design a linear page first, and
then tackle a way to fold that design into a 2-D design, without
breaking the linearization. With CSS this is fairly easy, and clever use
of tables can also be used. The interaction of browsers and screen
reader capabilities can present problems. For example, when I tried a
default read-through of a page in Window-Eyes it linearized the page,
but when I went line by line, it read horizontally across the page, like
an older screen reader, cutting through table boundaries. This was the
virtual cursor mode I think, but I am not an expert with Window-Eyes.
JAWS however linearized the page when doing a full read or line-by-line.
Text and audio browsers, because they read the page code directly,
always linearize the page, it is just the screen readers that may have
these variables of read order. The user has to know how the different
reading modes of his or her technology is processing the page, so there
is a learning curve associated with a particular technology that the web
designer cannot control.

TEXT-ONLY IS NOT SUFFICIENT.
The text-only idea is all right but it only benefits a portion of users,
and I think it represents a 'quick-fix' mentality where one does
'business as usual', that is, design a site however one wants, and then
add a system to hopefully extract an accessible version from it without
having to think much about accessibility. That is the extreme view, but
I think it pegs the majority of design and development thinking these days.

POST DESIGN ACCESSIBILITY FIXES.
Clearly the LIFT system has some refinements for creating the text-only
version of a site. For visual browsing, say with magnification, a
tables-off, style-sheet off view of the usablenet.com home page was
superior to the text-only version for general readability, primarily
because the style sheet for the text-only version of the page removed a
number of visual cues such as font-size for headings that would be seen
in a CSS-off view of the page. In fact there was no information in the
page that was really any different except for the linearization of
tables. This pre-linearized version however is a plus for small screen
devices, screen magnification, and older screen readers.

A user of the Opera browser using the user views with this home page
would be able to have a low vision experience that was much richer and
informative than the LIFT text-only version, and could get all the
information in the page simply by toggling images on and off, and would
get more visual cues as to the structure of the page. The LIFT text
transcoder allowed increase (or decrease) of text size, but the controls
were near the bottom of the page where a low vision or blind user, would
not notice for a while, and when I went to another page on the site, the
font-size change was reversed. In this case it seems the transcoder
would largely be redundant for anyone that has decent assistive
technology. The transcoded page and the original page looked identical
in the Lynx text browser. Clearly the transcoding process works best
with a page that is already essentially accessible. I don't know how
well it will work with a page that is essentially inaccessible.

The decision for the CSS to format the page, presumably a decision
independent of the transcoding process, interestingly was one major
element in why the transcoded page was much less informative and duller
than the regular presentation in some assistive technology. This
indicates somewhere in the decision chain leading to the text-only
presentation of the page, an accessibility unfriendly choice was made, a
choice clearly the result of human knowledge and not the technology
itself. Muddle management?

Designing proper linearization, text alternatives, and other
accessibility requirements from the beginning is more fruitful, but as
the conventional thinking of designers and developers is a strong point
of resistance here, fix-it workaround systems are going to arise in the
attempt to surmount that. What LIFT needs for example, is a means to
discriminate which images should be displayed and which ones can be
ignored or converted to text. But then, how much up front preparation
would be required for that to work? To be sure a single page example
does not demonstrate the potential of a technology, or even what
features it really has, so I could be missing something the transcoder
can actually do, but it would be fruitful to see how this system works
on a site that is really badly designed for accessibility. I believe IBM
is also working on a similar system. Putting such tools on the server
does remove some necessity for user to have to know what to purchase,
and how to configure tools to get a more accessible presentation. To be
fair to usablenet.com they do make a lot of tools to help designers make
accessible web pages that are also usable.

EDUCATION.
We are still up against lack of education about accessibility and its
advantages for all users, and entrenched habits of design and marketing
that are eroding rather slowly. Jakob Nielsen reported recently that a
review of his recent projects indicated that over one-third of all tasks
performed by users on web sites fail, and this is, I presume, mostly non
disabled users. In an environment like this does accessibility have much
chance? We are still up against the basic dichotomy in web design - the
desire of designers to absolutely control the presentation and the need
for users to absolutely control the presentation.

What is the best way to light a gas stove?
1. Search out a fire from a lightning strike and bring it to the stove.
2. Rub two sticks together near the gas.
3. Strike two rocks together near the gas.
4. Call the 'keeper of the fire' over to get the starter flame.

Terence de Giere
<EMAIL REMOVED>



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