WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Linear Access and Text Only

for

From: Giorgio Brajnik
Date: Dec 5, 2003 8:14AM

Hello. I'm responding as a Usablenet advisor.

Thank you, Terence, for the analysis described below. I agree with
most of the points you make. And I'd like to take advantage of your
message for responding not only to your comments, but to all the
people that contributed to this thread. Sorry for the rather long
answer.

Please see also some notes published on
http://www.usablenet.com/accessibility_usability/textonly.html .

Giorgio Brajnik
______________________________________________________________________
Dip. di Matematica e Informatica | voice: +39 (0432) 55.8445
Universita` di Udine | fax: +39 (0432) 55.8499
Via delle Scienze, 206 | email: <EMAIL REMOVED>
Loc. Rizzi -- 33100 Udine -- ITALY | http://www.dimi.uniud.it/~giorgio



On Fri, 04 Jul 2003 15:19:29 -0400
Terence de Giere < <EMAIL REMOVED> > said:
> ...
> 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.


I agree that tools like LIFT Text Transcoder need to handle also
images. It's something UsableNet is working on already. But absence of
this feature does not mean that those that are available aren't useful
at all. Or that text-only pages are evil, like it sometimes seems to
be according to some posted message.

> 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?

I believe you refer to the fact that transcoded pages show a DOCTYPE
with HTML 4.01 even though the original pages they depend upon are
written in XHTML. This is the result of a design compromise within
LIFT Text Transcoder, that has to be able to parse and process almost
any possible combination of HTML tags (no more, no less than a normal
browser has to do). Since automatic formatting of arbitrary HTML "tag
soups" is out of scope for LIFT Text Transcoder, the result is that in
general it cannot produce code that conforms to XHTML. Not even if the
original page does so because of the way pages are processed. (BTW:
performance of LIFT Text Transcoder is an important requirement, and
therefore somewhere UsableNet designers had to draw a line of what is
feasible and what not.)

> 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.

All true but how many users know how to use 100% of the features
offered by their browsers? Having some of those features available on
the webpage itself makes it much easier to use them.

The transcoder that is currently being used in
http://www.usablenet.com is version 1.0 of LIFT Text
Transcoder. UsableNet is going to release in a couple of days LIFT
Text Transcoder 1.2, which is much improved. You can try it on a free
demo service by going to http://demott.usablenet.com:8080/tt . And if
you visit some of the websites UsableNet has been working with
recently, for example
http://demott.usablenet.com:8080/tt/http://www.lifescan.com/care , you'll
see the kind of results that LTT is capable of producing. Of course
UsableNet will be happy to give you a more detailed demo with a
discussion of the annotations required to customize LTT, if you ask it.

And as any other tool, everything is perfectible. So there should be
no wonder that also LTT has some defect. And that it can be improved
in a number of ways. Like what you say about LTT controls being too
hidden, or it not preserving images. UsableNet is following a certain
route that I think will make LTT an even more powerful tool for
supporting accessibility and (therefore) interoperability of a
website. Constructive criticism is always beneficial. Dogmatic
positions aren't.

> 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?

Well, it depends on the complexity of what you need to achieve. For
the LifeScan site I mentioned above, it took basically less than one
day to identify some defects and write the appropriate annotations for
fixing them. UsableNet is working on a SDK for LTT so that webmasters
can develop their own set of annotations. And of course there will
always be things that cannot be achieved. But there are plenty that
can.

> 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.

Thank you. One example cannot prove anything other than feasibility. But if
you go to usablenet.com and ask for a free demo (even though it will
cost you submitting your email address to a company :-) they will be
happy to highlight the LTT features and you can get a deeper insight
of what works and what doesn't.

> 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.

As a final remark, I'd like to say that in my opinion there is no way
that web designers will keep absolute control of presentation, content
and interaction structure of websites. This dichotomy is going to be
resolved in only one direction: user control. Text transcoders are just
yet-another-way that a web visitor can choose to use a site.

Best regards,

Giorgio Brajnik
______________________________________________________________________
Dip. di Matematica e Informatica | voice: +39 (0432) 55.8445
Universita` di Udine | fax: +39 (0432) 55.8499
Via delle Scienze, 206 | email: <EMAIL REMOVED>
Loc. Rizzi -- 33100 Udine -- ITALY | http://www.dimi.uniud.it/~giorgio


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