WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Linear Access and Text Only

for

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

From: Terence de Giere
Date: Thu, Dec 04 2003 1:26PM
Subject: Linear Access and Text Only
No previous message | Next message →

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 ADDRESS REMOVED =



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

From: Giorgio Brajnik
Date: Fri, Dec 05 2003 8:14AM
Subject: Re: Linear Access and Text Only
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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/

From: julian.rickards@ndm.gov.on.ca
Date: Fri, Dec 05 2003 8:26AM
Subject: RE: Linear Access and Text Only
← Previous message | Next message →

I tried the demo out on a page from one of my sites
(http://cuac.org/members/index.php) and noticed that the alt text of the
header graphic was displayed in the demo page as blue (bold) with a blue
underline which to many means it is a link but it isn't. In the graphical
page (the original), the compass graphic area of the header image is an
image map hotspot which is pulled out as a link - that is good -- but I
don't like the blue underlined image alt text.

---------------------------------------------------------
Julian Rickards
Digital Publications Distribution Coordinator
Publications Services Section
Ontario Ministry of Northern Development and Mines
Phone: (705) 670-5608
Fax: (705) 670-5690


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


From: Karl Groves
Date: Fri, Dec 05 2003 8:56AM
Subject: RE: Linear Access and Text Only
← Previous message | Next message →


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

I found this comment to be particularly ridiculous.
Users who need those features will likely be quite familiar with them - this
is particularly true of the browser's accessibility settings.

In addition, I should remind you that your company's name is "UsableNet".
As such, one can only assume that you'd be familiar with the concept of
learnability.
A good website is created in order to a)minimize the overall amount of
things the user needs to learn to interact with the site and b) minimize the
time/ effort needed to learn to interact with the site. If anything, your
tool is introducing new things the user has to learn on the particular site,
while they are far more likely to have already learned their browser's
features. By having the controls near the bottom of the page, you've also
increased the time necessary to learn the new way of interacting.

Karl Groves, Master Certified CIW Designer
http://www.karlcore.com






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


From: Terence de Giere
Date: Sat, Dec 06 2003 8:51PM
Subject: Re: Linear Access and Text Only
← Previous message | No next message

Giorgio -

Thanks for that long reply to this thread.

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.

When I referred to the CSS (Cascading Style Sheet) on the Lift Text
Transcoded page, I wasn't referring to the Doctype. There is a small
embedded style sheet that adds some format to the page, and it overrides
some of the format one would get if the page were displayed in a
graphical browser without CSS, such as tiered heading font sizes for
headings. The default presentation of HTML in graphical browsers without
CSS is generally quite readable, and gives a page some useful visual
structure. I assumed this added style sheet could be modified in the
transcoder, and that a more elegant style sheet could be provided. The
sample link you provided indicates that is true. HTML or XHTML written
according to the specification will display well without a style sheet,
but HTML tag soup, as is so often found on the web is a problem.

I tried the transcoder on some valid XHTML and HTML pages and the
resulting code in the transcoded pages was valid HTML 4.01. Pages that
were not valid to begin with did not result in valid HTML in the
transcoded pages. I do not see how that could be fixed without the
chance that some page content would be deleted.

One valuable transformation the transcoder makes is linearizing the
page. Not all combinations of browser and screen reader can do this so
this a valuable feature. It also kept intact a small data table I tried
with it, which would let the table navigation controls of recent screen
readers and browsers like IBM HPR to function properly. Tables can be
particularly difficult. A linear one column text version of a data table
can be more comprehensible in assistive technology provided it can be
restructured so that the headings etc. are properly associated with the
data. If the LIFT transcoder could provide such an alternative version
of a data table (along with the original table), it would help a lot
with older assistive technology and less sophisticated screen readers.
It would also make tables understandable on small screen technology and
in text browsers which do not retain a table grid for display.

I was wondering about Frames. The transcoder processes them in a manner
much like a text browser that recognizes frames. Suppose the individual
framed pages could be presented without the frames in a single flat
file. This might make it easier for navigation. For example on the
Universit