WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility Observations

for

From: Terence de Giere
Date: Feb 26, 2002 10:07PM

The issue of linearization in a Web page is a tricky one.

COMPLEX GRAPHICAL PAGES FOR DATA ENTRY AND RETRIEVAL.
There are many processes that can be made very efficient for normal
users with a graphical interface. An example would be a very dense
screen used by employees of a courier service for tracking packages.
Such a screen would have multiple options, scripting functions, data
windows etc. Typical users would be trained in the use of such an
interface, allowing it to be more complex than a typical screen on the
Internet that would be used by first time user.

RETROFITTING LINEARITY.
Making such a dense screen accessible and usable for a screen reader can
be quite difficult, especially trying to linearize the tasks in a
meaningful way. Once the visual relationships are gone, a lot of the
efficiency and power of the interface is lost. A new set of
relationships needs to be created for linear access, perhaps with hidden
links (images with ALT text in links) or a short list of links to index
the page.

NESTED TABLES.
The only way, for now, to linearize complex pages with intense graphical
layouts is with pages which have many discreet complex areas created by
making nested tables. Any browser or browser/screenreader combination
that can read tables will linearize the sequence of the page properly.
But those nested tables will present barriers for users of some kinds of
technology, ones that cannot turn off reading of table structure. Just
having a new table itself announced every few words could be annoying;
some technology will read the start of every row and cell as well.

Many sites use nested tables to precisely position page items as well.
This can create a large number of nested tables whose function is not to
establish the linear flow of the information in the page; they may even
scramble the order of presentation with the most recent assistive
technology.

Because tables still need to be used to create graphical layout,
attempting to simplify and reduce the number of tables can help.

OLDER SCREENREADERS.
Some combinations of browser and screenreader cannot read information in
columns created by tables. Those readers just read horizontally across
the screen, cutting across the table boundaries and making the page
incomprehensible. The only solution for these users is a single column
page.

FRAMES.
Frames also break the linearity of presentation since it forces
non-visual users to go to separate pages to get information. While these
pages appear as a single interface in a graphical browser to the sighted
user, this is not so for everyone using text, audio or Braille access.
For a few, of course, frames do not work at all.

CASCADING STYLE SHEETS LEVEL TWO.
The solution is Cascading Style Sheets Level Two (CSS2). Unfortunately
the positioning aspects of CSS2 are still limited and quirky in the most
recent incarnations of the graphical browsers. The recent browsers
however, show the promised land is getting closer.

EXPERIMENTAL LINEAR PAGES WITH GRAPHICAL LAYOUT.
I have created experimental pages that are one column, linear, meet the
W3C Level Triple-A accessibility compliance requirement, and display
with a fixed top and left menu for navigation, and have scrolling
content as with frames. All these effects can be created with CSS2. No
frames, no tables.

*The pages have relative sizing so the user can change the font sizes
for the content and menus. If the graphical screen is small the menus
reflow to the next line for the top menu, and a scroll bar appears in
the left menu. The pages use graphics only in the content area, although
of course they could be placed elsewhere too.

*The top menu is actually at the bottom of the page, and the left menu
just above it. Jump links to the navigation areas at the top of the page
are hidden for graphical screen display, but appear in text and
audio/Braille renditions of the page. This means for assistive
technology, the content can appear first on the page to provide more
context than a long string of navigation links. A couple of short links
can take such a user to those long-winded navigation menus, and present
a much shorter obstacle at the beginning of the page. Also search
engines will index more of the content first, and may display more of
the actual content rather than navigation bars in their search results
summaries.

*The pages have alternate style sheets so a linear display version can
be selected from the menu of browsers that support this feature. For
example a high contrast large text style sheet that also doubles the
size of the images was provided. The page, while totally plain, displays
fine with the default rendering of older that do not support CSS.
Without the "graphical" CSS the page can render well on a very small
screen. Alternately a more pleasing CSS that does not reposition
elements could be used for small screens. Of course audio style sheets
can also be included, once audio browsers and browser/screenreader
combinations support CSS2.

PROBLEMS.
There are problems however. Visually, different browsers do not process
all the CSS functions used: Internet Explorer did not scroll the content
or allow the menus to be fixed; Opera mangled the display of the left
menu. Netscape did not do well if the font size was increased too much.
However turning off the style sheet solves all those problems. Only
Netscape supported additional style sheets linked to the page, but did
not allow the user to use their own style sheet. All the browsers showed
glitches in format.

THINGS WILL IMPROVE SOON?
It appears we are close to the time - older browsers notwithstanding -
that linear, device-independent pages can be created that can have some
decent graphical interest and still be highly accessible, and not
contain any layout tables or frames. The problem I see is, many graphic
designers have a certain dislike of layouts that reflow, change shape,
and may display with some significant difference on different browsers.
CSS is really a simple programming language and its format effects are
not as easily understood by many visual designers as is making a
beautiful drawing of an interface in a program like PhotoShop. I have
watched truly gifted visual artists struggle with CSS in HTML editing
applications like Dreamweaver. It is difficult to visualize the effects
of CSS without playing with it a lot.

INTERACTION
One of the major remaining problems is interactivity. Scripting, or
embedded that produce motion on the page, and instantaneous interactive
changes simply often fail with screen readers. And older technology and
browsers do not support these interactive features than do not support
scripting or plug-ins. Such interactivity can be very non-linear. There
does not seem to be a meaningful way to reproduce these effects with
more static, accessible pages other than to provide a wizard-like
sequence of form submissions or a transcript.

ACCESSIBILITY IN THE DEVELOPMENT PROCESS.

DEPENDENCE ON HTML.
Because accessibility is so HTML dependent, Web developers are in the
best position to understand the specific coding issues involved. There
seems to be a strong tendency to hand off accessibility issues to those
who code the final design for a site, simply because the developers are
the ones expected to deal with the issue as they create the actual HTM.

EARLY EMPHASIS ON ACCESSIBILITY.
But my feeling is as the Web progresses towards greater device
independence, accessibility really must be confronted early in the
development process, even before any basic page layout designs are
created. That is, accessibility for a site should be developed about
concurrently with data gathering and early usability testing. The
tendency to push accessibility to a later stage, such as during detailed
page design, or even after that, should be resisted. Just as testing for
usability early in the development process can save a project from major
and costly design errors, the same can be said for accessibility. After
all, any inaccessible page is unusable.

TESTING TEMPLATES
It may be necessary to create linear, testable templates in HTML or
XHTML early in the design process so that so it can be rendered in
assistive technology, both for usability analysis and testing with
assistive technology users. These could be simple HTML pages, the
equivalent of wireframe layouts created by usability specialists. This
method is partially backwards from the way sites are usually designed
now, which takes a visual layout, often usability tested early on with
low fidelity paper and partially functional screen tests (such as using
a block graphic image mapped to simulate links and other functions) and
leave the structure for the HTML to be created at the end of the process
of design.

Thus accessible/usable design may require doing some more coding up
front in the process. Then, once a satisfactory solution is found, the
page can be worked into a more detailed design and eventually formatted
into a graphical design using CSS. The trick, if the same page is used
for accessibility and the graphical layout, is to coordinate what is
possible and not possible with CSS to implement the graphical design,
and what kind of compromises are possible.

Creating an accessible, correctly structured HTML and adding format
later or working out details of both aspects of design - HTML structure
for accessibility, and graphical presentation concurrently is not
something most usability specialists, graphic artists and developers
have had much practice with. Right now usable accessibility tends to be
compromised in favor of graphical design and usability for normal users,
but I do not think this compromise will be ultimately necessary.

WE HAVE SOME BAD HABITS; GOOD LOOKS AND GOOD FUNCTIONALITY MAY BE DIFFERENT
A lot of problems are caused by habits we have acquired over the years
in attempting to give a more graphical shape to the Web, and we need to
start thinking anew about how to approach Web design for greater device
and browser independence. Remember, a consistent finding among usability
experts is what a user says about a design as far as "likeability" or
preference for the way it looks often does not correspond with the
design that works the best to get a task done or to get a message across
or to sell a product. And we all have a tendency to become attached to
what we feel is a good design, and to misapprehend the surface value of
a design for deeper levels of functionality .

I have some user style sheets I use to analyze Web pages for
accessibility problems. I often find that it is much easer to use a page
with these style sheets than the design the designer had, even though
from an artistic standpoint they make the page look terrible. Giving the
user the ability to change the appearance or non-visual rendition and
even the functionality of a page to great degree to suit preferences and
accommodate disabilities is a real challenge to a designer. Instead of
making a single good design for just normal folks, we need to make in
essence multiple designs for a single page, without having separate
pages for each design, and have that multifaceted design remain usable
and functionally intact through all those transformations.

The idea of a fixed immutable design does not work with the second
generation Web. Device independence and good accessibility require that
the basic information structure and navigation of a page and a site hold
up under a lot more diverse conditions than that of simply looking and
functioning the same on Internet Explorer and Netscape on a desktop
computer monitor with a fast connection for a normal, sighted,
mouse-happy user.

Terence de Giere
<EMAIL REMOVED>



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