- From: Leonard R. Kasday <kasday@acm.org>
- Date: Thu, 18 Nov 1999 13:25:19 -0500
- To: Charles McCathieNevile <charles@w3.org>, Scott Luebking <phoenixl@netcom.com>
- Cc: w3c-wai-ig@w3.org
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)
Received on Thursday, 18 November 1999 13:21:55 UTC