WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility Observations - response to Holly

for

From: Terence de Giere
Date: Feb 28, 2002 12:45AM

THE ACCESSIBILITY OBSERVATIONS THREAD SEEMS TO HAVE INSPIRED A LOT OF
WONDERFUL COMMENTS. Holly Marie made some good observations on some of
the things I said, so I suppose I should defend myself, or amplify my
statements by way of her more pointed comments, which, based on what I
had written, are true.

TERENCE'S ORIGINAL STATEMENT
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.

HOLLY'S COMMENT:
Nesting tables is not the only way to do this, not now.

Not true and should NOT be used. Nested tables can lead to the one of
the more innaccessible ways to deliver a page if not extremely careful,
AND nesting tables is NOT allowed in XHTML Strict. It not only confuses
the screen readers and screen reading browsers, it confuses many devises
and mechanisms that parse page code and deliver the result.

The same effect can be delivered with Style sheets, and divisions.

TERENCE'S RESPONSE

Yes, this is right. However I have had to produce templates that really
required tables because of a browser support issue. The only way to
linearize the design for the assistive technology in question was to use
nested tables, not CSS. While this knocks off certain assistive
technology, it allowed a very dense design that linearized properly with
recent versions of JAWS, Lynx, and the now defunct pwWebSpeak32 audio
browser. This was for an intranet for which presumably, or hopefully,
the company could control the hardware and software used. The design was
created by a team of ergonomists, and while the goal was to be
accessible, accessibility was really given a brush over and the final
result was technically correct according to the rules, but difficult to
implement as usable accessibility at W3C Level A. Unfortunately
accessibility is not always the key element in a design, but a
compromised element. In this case highly usable visual design with
extreme compactness for a lot of material and navigation were the
primary goals.

I agree that nested tables for format and positioning are really bad,
but with the most recent screen readers, it does work, because the
screen readers are not just reading what the browser prints to the
screen but have hooks into the browser itself, allowing it to get
information on the HTML element structure. I prefer the DIV method
myself, but do not like absolute positioning with pixels or fixed
measurements in most cases, if the desire is to create a page than can
fit multiple screen sizes including rather small ones, such as on a
graphical PDA browser that supports CSS.

Nested tables are a technique for linearizing the text flow with certain
assistive technology. The Section 508 rules do not prohibit this. And
single column pages are only required by Level Triple-A conformance in
the W3C WAI guidelines: 10.3 Until user agents (including assistive
technologies) render side-by-side text correctly, provide a linear text
alternative (on the current page or some other) for all tables that lay
out text in parallel, word-wrapped columns.[Priority 3]. This is the
last level you can expect a corporation to spend money accommodating.

I was thinking of the issue of older browser support, and specific
problems of CSS support using percentage values with absolute
positioning rather than fixed measurement such as pixels or centimeters,
etc. The best CSS browsers still do not handle this more relative use of
"absolute" positioning very well, with especially annoying variations in
the positioning of boxes and problems with overlapping incorrectly and
text overlapping incorrectly. Rendering this fluid, unfixed layout must
be difficult for the developers of browsers to figure out and code. They
just have not got it yet. Forgive my incompleteness, but there is always
more to learn and remembering everything is for the gifted few.

TERENCE'S ORIGINAL STATMENT:
Because tables still need to be used to create graphical layout,
attempting to simplify and reduce the number of tables can help.

HOLLY'S COMMENT:
Again this is not true, there are many ways to present graphical layout
without the use of nesting tables, without the use of tables, and with
the current elements of code and guidelines.

TERENCE'S RESPONSE:
Yes I agree. But if you want to accommodate visually some of the older
browsers, tables may be the only way to implement a graphic design. I
had to create templates for a group that included teachers, who tend to
have older browsers and the company specifically required that Netscape
3.0 be supported, and there would be no coding to customize for specific
browsers. To make the design work for the browser mix, tables had to be
used, and accessibility was not part of the specification. Had
accessibility been implemented, Section 508 or Level A, it would not
have been ideal but would have been workable with this use of tables. So
if tables must be used, alas, simplify if possible. By the way, the
graphic designer that created the visuals for the site referred to here,
when left to his/her own devices produces completely inaccessible sites,
and uses graphics without ALT text for everything including most text on
the page.

Note that the W3C home page still uses a simple table for layout in
three columns; not nested, which is good. Interestingly, a link to an
alternate page that was only one column now seems to have been removed.
Again forgive my incompleteness, but practical realities, unfortunately,
are often the bane of accessibility.

TERENCE'S ORIGINAL STATEMENT:
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.

HOLLY'S COMMENT:

Now here is a nice sticky area. Do we as designers and developers
continue to design backwards for old technologies and browsers or do we
fully embrace the guidelines and current rules or suggested coding and
leave it up to the end user to bring themselves up to the current
technology.

Do we continue to design for NN4 and older versions, keeping that type
of incomplete and backwards code alive, or do we all try to move forward
and at the same time the people developing and or using older technology
will need to upgrade?

Isnt it our job to follow the recommendations and code to guideline and
then the end user's job to make good use of the technology as it should
be? Coding for accessibility is not easy, but not impossible, and can be
easier than some ways are portrayed. A good dose of common sense is
quite often the missing element. The other is an awareness that
accessibility is NOT only about the blind, but also about dyslexia,
reading difficulties and non readers, motor challenges, normative aging
and age ranges of users, hearing and hearing impaired, and many more
considerations. Including the usability and challenges of a *normal
average* user.

TERENCE'S RESPONSE:
O that those older browsers would expire, primarily the ones that
support CSS incompletely. Each Web site has some agenda behind it. Where
to break off support is always a big issue. For accessibility supporting
older technology is good, because these AT (asssistive technology) users
may be using older computers and browsers as they tend to have less
income for upgrades etc. Right now I have a blind friend who is stuck
with Windows 3.1 and older assistive technology.

However for supporting accessibility, one does not necessarily have to
support the visual aspect of CSS format for those browsers. Turning off
CSS support at the server is best (browser detection and ASP or JSP or
similar page construction that can substitute different style sheets or
leave them off), but less technically constructed sites may have to do
with single pages and no ability to control the issue. Using JavaScript
is less perfect, because the user could turn it off, and forces one to
add a NOSCRIPT equivalent or explanation. If more than one person is
involved in the decision, you may have to compromise. My personal
preference is to aim for the Web standards. The Web really needs a
standard API for all this to work. Anybody want to vote on which CSS
browsers to axe? I vote for Internet Explorer 3.x and Netscape 4.x, to
start.

TERENCE'S ORIGINAL STEMENT:
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.

HOLLY'S COMMENT:
I have to disagree here and worked a fully compliant absolutely
positioned page that not only lays out well in all browsers... NN4x,
IE5.5, Opera, Mozilla, and NN6, but it also degrades gracefully and in
clear order on a text only render in Lynx or browsers with sheets and
styles off. So that is a bit of misinformation. The pages coded to XHTML
strict without error or warning and the pages also coded to CSS2
Validation with no errors and no warnings, and on further check read
well on text only. So it can be done well and does work well enough both
visually and contextually.

TERENCE'S RESPONSE:
Again, without stating fully what I was thinking, I was referring to
absolute positioning with percentage values that do not yet work well
across the browsers. Holly's example shows that absolute positioning
with fixed units of measurement is quite workable.

However Holly's page linearized in Opera 3.62, the first CSS version of
that browser which only supported CSS1 and not CSS2 positioning, and was
difficult to read as text overlaid the grid background graphic.
Fortunately that version of Opera allows quick switching to a user mode
that removes the style sheet format. Using relative values is a Prioity
2 item with the current W3C rules and so for Section 508 and W3C Level A
accessibility compliance, we can ignore and use fixed font sizes and
fixed page widths etc., which some browsers do not allow the user to
override, at least without going deep into the browser preferences.

The usability expert Jakob Nielsen found that users using screen
magnification performed less than half as well on tasks as normal
sighted users. With a fixed width page enlarged, horizontal scrolling
becomes a big usability issue. The goal is to try to reduce the
scrolling by having the page reflow and become narrower for these users.
Of course with really big enlargement, this cannot be fully prevented.
Some users, such as those with advanced macular degeneration may have to
read almost letter-by-letter.

The example Holly created is quite nice at
http://www.qexo.com/access.html. The font size is normal - not too small
like most Web sites these days. The contrast may be too low for some
users. The orange background and blue links is slightly chromosterioptic
and should be avoided. Chromosteriopsis results when colors are side by
side as text on a background and the wavelengths focus at different
depths in the retina causing a 3D effect of the text lying outside of
the plane of the background. Red and blue is the worst combination. The
effect on Holly's page is much more subdued as the wavelengths are
closer together.

EXPERIMENTAL LINEAR PAGES WITH [CSS] GRAPHICAL LAYOUT.

HOLLY'S COMMENT
If these areas for the menu and navigation are fixed, what happens to
the text when a users resizes it say 300% or more, does that content get
cropped off or hidden? (do you have an overflow statement for the
content in the css?)

TERENCE'S RESPONSE:
In these pages the menus were not completely fixed. They could reflow to
some extent. There is a problem with increasing text size right now. The
Mozilla browsers do not increase the line height if line-height
specified in the CSS and so the text jumbles together. Internet Explorer
handles this situation much better, by proportioning the line height to
the text. Opera also handled text size increase fairly well, but
normally in Opera one can just magnify the whole page more easily. There
is a way to go here as far as how the browsers handle this issue. There
seems to be some hope, but it is not right yet. Internet Explorer could
not position the menus correctly on the page without absolute
positioning (The ideal sample used fixed positioning so the menus were
always visible, or scrollable).

As for the skip links, these were *to* the navigation area, not to skip
over it. The navigation links on the page were not where they appeared.
In Opera the first element on the page accessed when in graphical mode
was the first H1 Heading in the content area. You have a point about not
being able to see the links though, if the user needed to get *to* the
navigation and had such restricted mobility. Keep me thinking! I am all
for just putting these links in text and be visible, but graphic
designers often hate this, so part of the experiment was to hide them.
This is where usability testing can be helpful. More experience is also
more helpful in solving these kinds of problems. It does not appear we
will be able to solve all the problems equally well to the satisfaction
of everyone.

ACCESSIBILITY IN THE DEVELOPMENT PROCESS.
DEPENDENCE ON HTML.
Actually the current dependence is on the HTML element names. These were
of course carried over into XHTML. Pure XML without predefined element
names such as H1, H2, H3 etc. does not have any standard way to
establish document structure for accessibility unless the element names
become standardized and supported by the technology. Otherwise it
becomes necessary to have a style sheet (CSS or XSL) provide the proper
rendering, which won't work in a non-CSS or non-XSL browser.

As for Holly's other comments, she will keep me on my toes. Design is an
iterative process. Exactly what must be done first, the text-only
sequence, or some graphical layout? In the end it may come out the same.
I have focused on issues related primarily to non-sighted, or text
access, which requires a text-based approach to the content, but Holly
wisely pointed out that multimedia and imagery is essential for certain
learning disabilities.

(Holly, I am a photographer, with a passion for landscapes, and have a
very non-verbal approach to imagery, at least in photographic media; I
am slightly rusty at it since I have been in front of a computer for the
last half-decade.) A picture is worth a thousand words both in content
and code size. One of the most difficult things to do well is describe
pictures well and completely in text. Another difficult task is
designing usable multimedia and also making that material accessible to
those that cannot experience imagery or sound.

For those with textual impediments, does this mean that we have to
create imagery-only equivalents to predominantly text based pages? My
guess this would be done for special training programs, but ordinarily
would be overlooked as a possibility since accessibility guidelines
focus more on text equivalents for multimedia rather than the opposite.

I found everyone's comments on this thread of general accessibility
observations really illuminating. Thank you everyone for such a spirited
collection of useful comments. We all learn, and when we forget
something, it reminds us.

Terence de Giere
<EMAIL REMOVED>



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