Scott,
Regarding your example of the letters "GROWTH" laid out starting in the
lower left and traveling up and to the right. You're asserting I believe
that it would be hard to use tables in such a way that it linearizes to g r
o w t h. Indeed, if all you did was lay out these 7 letters in a 7 by 7
row they would get read out backwards. But it's pretty easy to make them
read correctly. See
http://astro.temple.edu/~kasday/wai/tableorder.html
I agree with Charles by the way that if all you're trying to do is create a
visual effect then an image would be better, with alt text description.
However, we can still look at your example as an abstract challenge, which
is what I did.
I don't understand the Z example.
Len
At 07:21 PM 11/17/99 -0500, Charles McCathieNevile wrote:
>Scott,
>
>There are some things that cannot be currently done accessibly. For those
>things there are a few alternatives:
>
> 1. Just don't. Consider whether something is really necessary, as well as
>how it will appear. In addition, consider waiting for better technology, and
>using it when it becomes available. Scalable Vector Graphics makes it easy to
>achieve such effects in a form that will linearise perfectly well, containing
>plain text that can be searched, selected, retrieved by search engines and
>other metadata harvesters, etc.
>
> 2. Use the best technology available. To make the word growth travel
>diagonally up the page will break down in all kinds of situations. If it is
>really necessary, the best solution may be to use an image, or a cascade of
>object elements.
>
> 3. Make a separate version. Unless you make it very obvious that there is
>another version, and that it is up to date, this is not worth considering,
>but as a last resort it is better than nothing. However, in the case where
>this is the chosen approach, don't just amke a "text-only" version. There are
>many features of accessible design that go beyond text, and many features of
>ordianry design that are easy to use and valuable in an accessible version -
>images, structure, well-designed actve elements, etc etc.
>
>cheers
>
>Charles McCN
>
>
>On Wed, 17 Nov 1999, Scott Luebking wrote:
>
> Hi, Len
>
> I believe that the thread on tables may not be finished yet.
>
> The issue of tables has a lot to do with positioning text
> and also with color backgrounds. For example, if there is a left column
> index and a main column with header and body, the column index is read
> first. Nested tables for alinging blocks of colors in certain
> ways in a column is another problem. Because there can be so
> many ways to use areas of color on a web page to create a certain
> design effect, I would be careful not to make the assumption that
> linearization is always readily achievable, e.g.:
>
> H
> T
> W
> O
> R
> G
>
> (For screen reader users, this is the word "GROWTH" with the letters
> starting at the lower left corner and going towards the upper right.)
>
>
> Z Z Z Z Z Z Z
> Z
> Z
> Z
> Z
> Z
> Z Z Z Z Z Z Z
>
> (This is a Z, made up of a lot of Z's.)
>
> I'm not saying that default page should be impossible to use, but that
> in a trade-off between visual appearance and visual accessibility, it
> will be hard for designers to give up visual appearance.
>
> Scott
>
> >
> > OK, we agree that giving a choice is desirable... although we might
differ
> > on how desirable. I'd also agree that we can't ignore how much effort it
> > will be for a webmaster.
> >
> > As for your assertion that
> >
> > >layouts using tables probably won't transform very easily into a more
> > >linearized form.
> >
> > Another thread just popped up on on this list re problems with tables and
> > other folks are discussing various experiences with tables. We're seeing
> > different view there.
> >
> > My view is that it's not hard to avoid the table linearizing as
gibberish,
> > although you do have to use a few tricks. For example, if you want a
> > layout with several text fields in a row and you want the names on top of
> > the text fields, you can't just put names in a row above the text fields.
> > If you did that a screen reader would read all the names and then present
> > all the fields. A real mess. But in this case you can easily put each
name
> > and text field in their own table cell, with a break <BR> in between.
That
> > gets the reading order correct.
> >
> > Of course, I'm assuming that the browser or browser screenreader is reads
> > the table in the order it appears in the HTML. This is true of text or
> > voice browsers like lynx, pwwebspeak, emacs/w3, and home page reader, as
> > well as graphical browsers-screenreader combinations which linearize
> > tables, like internet explorer and jaws with the reformat command.
> >
> > Now, that doesn't always put the items in the order that yields maximal
> > efficiency. In fact, it can be rather messy... e.g. users hear the main
> > menu links, the title, some of the links again (when they are featured
in a
> > center splash image) etc. I agree that it could be made better on a
> > separate page with different format.
> >
> > So yes, I've said it before and I'll say it again, would indeed be
valuable
> > to have alternative versions of the page which are easier to read in an
> > efficient manner.
> >
> > But my point is that I still feel that even the default page should at
> > least avoid gibberish and not be completely impossible to use.
> >
> > Is there an example you can give where it's really tough to avoid
> > gibberish... an example that would come up commonly?
> >
> > Or if anyone else out there has a good example please post it up on
the list.
> >
> > Len
>
>
>--Charles McCathieNevile mailto:charles@w3.org
>phone: +1 617 258 0992 http://www.w3.org/People/Charles
>W3C Web Accessibility Initiative http://www.w3.org/WAI
>MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
>
>
>
-------
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University
423 Ritter Annex, Philadelphia, PA 19122
kasday@acm.org
(215) 204-2247 (voice)
(800) 750-7428 (TTY)