RE: Stylesheet columnisation

   
Len:
I'm still unclear.
I use JFW 3.2 with IE 4.01 and it is not smart enough to do that automatically.  If things don't make sense, I know to try the "Reformat Page" commandd (In WCAG terminology, a "table linearization or serialization command) which, may, if the page is coded correctly, make sense when llinearized.
I was really getting at the issue you mentioned.  It does not really matter whether  HTML tables or CSS is used for layout.  Either method will cause accessibility difficulties (rather large difficulties, - the user not being able to make sense out of what is being read).
I interpret The main theme of the guidelines to be the crucial distinction between content and structure on the one hand and presentation on the other.
HTML tables were intended to be used for tabular data, as is pointed out many places.
To use tables for layout is a misuse of tables.
To say that 
CSS is not widely supported 
implies 
it is o.k. to go ahead and misuse HTML  tables for layout anyway just seems to be sending the wrong message. 
If tables should not be used for layout, they should not be used for layout, whether or not CSS is currently widely supported.  This does not mean CSS must be used either.
Layout is a presentation issue, not a content or structure issue. 

If layout is actually used for structure then a one dimensional linearization of a two dimensional layout is certainly not equivalent access.
Do you agree?
Restricting the discussion to the use of CSS 
"Do you agree with that?"  Then we can get to triple A.
the short answer is yes.  Perhaps we are talking on different levels/scope.
-Steve

>>> "Leonard R. Kasday" <kasday@acm.org> 11/05/99 02:16PM >>>
Steve,

(Caveat: this is all my personal opinion, not an "offical" interpretation).

I think I understand why you're uncomfortable with the emphasis that came
out of what I said.  I was spotlighting practices which we all know give
less than maximal accessibility, yet still rate double A, or even triple A.
 I don't like that either.

But here's the actual text.

3.3 says "Use style sheets to control layout and presentation. [Priority 2] "

Yes, that looks like using tables for layout rules out a double A.
                   
However, there is a note on 5.3 that says

"Once user agents support style sheet positioning, tables should not be
used for layout."

Since CSS layout isn't supported yet I read that note as providing an
exception to implied requirement of 3.3 that tables not be used for layout.
So the page can still get a double-A.

Another way to look at this is that if you're using a screen reader which
only reads straight across the physical information on the screen, instead
of looking at the underlying HTML or Active Accessibility information, I
think it will fail just as badly on CSS layout as it would on Table driven
layout.  I can't test that directly because the combinations I have, like
lynx, MSIE/JAWS, pwWebspeak, etc. etc. are all smarter than that.  But I
think it has to be true.  So it doesn't seem to me worthwhile to insist on
the CSS layout here.

Do you agree with that?  Then we can get to triple A.

The question of what clarifying statements might be written for the
guidelines is  separate issue.

Len

At 07:56 AM 11/5/99 -0500, Steven McCaffrey wrote:
>   
>Len:
>With respect, I have to disagree on the emphasis.
>If the emphasis is indeed somewhat ambiguous (or at least mildly
confusing), the WCAG should be modified to make things more clear.
>I used square brackets to emphasize what I think should be the emphasis.
>Also, I see the guidelines concerning tables for layout and the use of a
text-only version as closely related.
>It is my experience that increasingly, the one remaining reason why a web
page designer has to resort to a text only version is precisely because
tables are being used for layout when there is no good reason (in my
opinion) for doing so.
>-Steve
>   
>
>"  
>Guideline 3. Use markup and style sheets and do so properly.
>  Mark up documents with the proper structural elements. [Control
presentation with style sheets rather than with presentation elements and
attributes.]
>Using markup improperly -- not according to specification -- hinders 
>accessibility. [Misusing markup for a presentation effect (e.g., using a
table for layout] or a header to change the font size) makes it difficult
for users with specialized software to understand the organization of the
page or to navigate through it. Furthermore, using presentation markup
rather than structural markup to convey structure (e.g., constructing what
looks like a table of data with an HTML PRE element) makes it difficult to
render a page 
>intelligibly to other devices (refer to the description of[ difference
between content, structure, and presentation]). 
>Content developers may be tempted to use (or misuse) constructs that
achieve a desired formatting effect on older browsers. They must be aware
that these 
>practices cause accessibility problems [and must consider whether the
formatting effect is so critical as to warrant making the document
inaccessible to some users.] 
>At the other extreme, content developers must not sacrifice appropriate
markup because a certain browser or assistive technology does not process
it correctly.  For example, it is appropriate to use the TABLE element in
HTML to mark up tabular information even though some older screen readers
may not handle side-by-side text correctly (refer to checkpoint 10.3).
Using TABLE correctly and creating tables that transform gracefully (refer
to guideline 5) makes it possible for software to render tables other than
as two-dimensional grids. 
>
>Guideline 5. Create tables that transform gracefully.
>  Ensure that tables have necessary markup to be transformed by accessible
browsers and other user agents.
>[Tables should be used to mark up truly tabular information ("data tables").
>Content developers should avoid using them to lay out pages ("layout
tables").] 
>
>Tables for [any use] also present special problems to users of screen
readers(refer to checkpoint 10.3). 
>Some user agents allow users to navigate among table cells and access
header and other table cell information. Unless marked-up properly, these
tables will not provide user agents with the appropriate information.
(Refer also to guideline 
>3.) 
>The following checkpoints will directly benefit people who access a table
[through auditory means (e.g., a screen reader or an automobile-based
personal computer) or who view only a portion of the page at a time (e.g.,
users with 
>blindness or low vision using speech output or a braille display, or other
users of devices with small displays, etc.).]..."
>
>
>   
>
>
>>>> "Leonard R. Kasday" <kasday@acm.org> 11/04/99 09:23AM >>>
>At 06:23 PM 11/2/99 -0500, Neff, Robert wrote:
>>As I understand the guidelines double-A, tables can be used for layout and
>>formating using HTML 3 and 4 and CSS.  If you want Triple-A then you cannot
>>use tables for layout unless you use CSS.
>
>I agree that for maximum accessibility you don't want to use tables for
>layout.  
>
>However, strictly speaking, the guidelines don't rule out tables for
>positioning until user agents support style sheet positioning (per
>checkpoint 5.3), and we're not at that point yet.  Furthermore, you can
>still get a triple-A by having a separate page without the table layout
>(checkpoint 10.3).  If I'm misreading these guidelines somebody please
>straighten me out. 
>
>Also, Masayasu Ishikawa pointed out in subsequent email that css 2 doesn't
>have true columns, in the sense of automatic text flow.  That makes me even
>more reluctant to push use of css for columns on a webmaster, since a year
>from now I'd have to tell him or her that it's gotta be changed again.
>
>Len
>
>>
>>		-----Original Message-----
>>		From:	Leonard R. Kasday [mailto:kasday@acm.org] 
>>		Sent:	Tuesday, November 02, 1999 4:00 PM
>>		To:	Neff, Robert; Kynn Bartlett; Paul Bohman
>>		Cc:	GARETH P PARKINSON; W3c-wai-ig@w3.org	
>>		Subject:	RE: Stylesheet columnisation
>>
>>		Bob,
>>
>>		You're asking whether using tables for layout is contrary to
>>Double-A,
>>		Right? Personally speaking I don't think so.  
>>
>>		Looking at
>>http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-table-markup 
>>
>>		We have
>>
>>		quote
>>		5.3 Do not use tables for layout unless the table makes
>>sense when
>>		linearized. 
>>		unquote
>>
>>		You have to be careful about that, but it doesn't rule out
>>tables for layout.
>>
>>		It then says
>>
>>		quote
>>		 Once user agents support style sheet positioning, tables
>>should not be
>>		used for layout.
>>		unquote
>>
>>		I read this to say that we can use tables for layout until
>>all user agents
>>		we might reasonably expect a user to have support style
>>sheet positioning.
>>		I think there's agreement we're not there yet. So this
>>doesn't require
>>		tables yet.
>>
>>		However theres
>>
>>		quote
>>		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] 
>>		unquote
>>
>>		So using tables for layout violates triple-A unless you have
>>a separate
>>		page that doesn't use the tables for layout. 
>>
>>		And if you do provide such a page, it better follow
>>		quote
>>		11.4 If, after best efforts, you cannot create an accessible
>>page, provide
>>		a link to an alternative page that uses W3C technologies, is
>>accessible,
>>		has equivalent information (or functionality), and isupdated
>>as often as
>>		the inaccessible (original) page. [Priority 1] 
>>		unquote
>>
>>		Or the page doesn't even get a single-A.
>>
>>		Len
>>
>>
>>
>>		At 01:52 PM 11/2/99 -0500, Neff, Robert wrote:
>>		>But isn't that contrary to the Web Content Accessibility
>>Guidelines
>>		>Double-A?
>>		>
>>		>		-----Original Message-----
>>		>		From:	Leonard R. Kasday
>>[le-A then you cannot
>>use tables fmailto:kasday@acm.org] 
>>		>		Sent:	Tuesday, November 02, 1999 1:38 PM
>>		>		To:	Kynn Bartlett; Paul Bohman
>>		>		Cc:	GARETH P PARKINSON;
>>W3c-wai-ig@w3.org 
>>		>		Subject:	Re: Stylesheet columnisation
>>		>
>>		>		Here's my short and extended opinions about
>>using tables for
>>		>layout.
>>		>
>>		>		Short opinion:
>>		>
>>		>		Given the current browser situation, we
>>can't use style
>>		>sheets for layout.
>>		>		Instead, use a table entirely for layout or
>>entirely for
>>		>data, but don't
>>		>		mix these uses in one table or nest data
>>tables inside
>>		>layout tables.  (Or
>>		>		avoid table layout altogether unless it
>>serves a real
>>		>purpose).
>>		>
>>		>		Also, help the reader identify when a table
>>is used for data
>>		>by:
>>		>		1. Including a caption of the form "Table of
>>blah blah
>>		>blah..."
>>		>		2. Using header cells in the top row.
>>		>
>>		>		Extended opinion:
>>		>
>>		>		1. Another advantage of tables is that with
>>current tools
>>		>it's easy to
>>		>		control the order in which the contents are
>>read, because
>>		>it's directly
>>		>		determined by the table layout.  Tools that
>>use CSS for
>>		>layout may produce
>>		>		a reading order that's very different than
>>the visual order.
>>		>This is
>>		>		because e.g. if you slide text blocks around
>>on the screen,
>>		>all the tool
>>		>		does is change the coordinates, not the
>>reading order.  This
>>		>happens for
>>		>		example with Microsoft Publisher.  Of
>>course, it's
>>		>straightforward to do
>>		>		this if you're writing raw HTML and CSS by
>>hand.  But you
>>		>run into problems
>>		>		with some visual type editing tools.
>>		>
>>		>		2. It's true that using stylesheets for
>>layout instead of
>>		>tables
>>		>		theoretically gives the screen reader a way
>>to deterine if
>>		>it's really a
>>		>		data table or layout control.  However, this
>>could easily be
>>		>done without
>>		>		style sheets, e.g. by requiring a caption on
>>all data tables
>>		>(even a null
>>		>		caption), or defining a class.
>>		>
>>		>		3. The current author guidelines permit
>>tables for layout
>>		>until browsers
>>		>		shape up, but require that they make sense
>>when read in the
>>		>order of the
>>		>		raw HTML ("linearized").
>>		>
>>		>		4. Therefore, perhaps we should permanently
>>allow the use of
>>		>tables for
>>		>		layout provided that a standard way is
>>agreed on to
>>		>distinguish layout from
>>		>		data use.  We've got time to think about
>>this since it
>>		>doesn't impact what
>>		>		we're doing right now.
>>		>
>>		>		Len
>>		>
>>		>		At 10:55 AM 11/1/99 -0800, Kynn Bartlett
>>wrote:
>>fthen you cannot
>>use tables f		>		>At 10:57 AM 11/1/1999 , Paul Bohman wrote:
>>		>		>>I noticed that, although you are
>>proficient at CSS layout,
>>		>you are still
>>		>		>>reluctant to use CSS for positioning. For
>>example, the
>>		>HTML Writers Guild is
>>		>		>>built on table layouts and the Aware page
>>		>(http://aware.hwg.org/) avoids
>>		>		>>layouts that would require either tables
>>or CSS
>>		>positioning.
>>		>		>
>>		>		>[...]
>>		>		>
>>		>		>>Even though I really like the concept of
>>CSS, I have my
>>		>doubts about its
>>		>		>>usefulness until browsers give it better
>>support.
>>		>		>
>>		>		>This is the crux of the matter.  CSS is not
>>widely
>>		>supported enough,
>>		>		>nor reliably supported enough, to be able
>>to use CSS
>>		>reliably for
>>		>		>layout.  In the case of the HTML Writers
>>Guild, there's an
>>		>extra
>>		>		>design consideration involved in that while
>>it's okay to
>>		>look "different"
>>		>		>in various browsers, we can't look "bad" in
>>any of them,
>>		>and if you
>>		>		>use CSS for positioning you take a serious
>>risk of looking
>>		>"broken"
>>		>		>in some browsers.
>>		>		>
>>		>		>(Most users, when they encounter a page
>>that doesn't look
>>		>right, will
>>		>		>think the page is poorly designed, not that
>>their browser
>>		>is deficient.
>>		>		>So the HWG site has to be created in a way
>>that it will
>>		>look "right"
>>		>		>cross-browser.)
>>		>		>
>>		>		>-- 
>>		>		>Kynn Bartlett
>>		>mailto:kynn@hwg.org 
>>		>		>President, HTML Writers Guild
>>		>http://www.hwg.org/ 
>>		>		>AWARE Center Director
>>		>http://aware.hwg.org/ 
>>		>		>
>>		>		>
>>		>		>
>>		>		-------
>>		>		Leonard R. Kasday, Ph.D.
>>		>		Institute on Disabilities/UAP, and
>>		>		Department of Electrical Engineering
>>		>		Temple University
>>		>
>>		>		Ritter Hall Annex, Room 423, Philadelphia,
>>PA 19122
>>		>		kasday@acm.org        
>>		>		(215) 204-2247 (voice)
>>		>		(800) 750-7428 (TTY)
>>		>
>>		>
>>		-------
>>		Leonard R. Kasday, Ph.D.
>>		Institute on Disabilities/UAP, and
>>		Department of Electrical Engineering
>>		Temple University
>>
>>		Ritter Hall Annex, Room 423, Philadelphia, PA 19122
>>		kasday@acm.org        
>>		(215) 204-2247 (voice)
>>		(800) 750-7428 (TTY)
>>
>>
>>
>-------
>Leonard R. Kasday, Ph.D.
>Institute on Disabilities/UAP, and
>Department of Electrical Engineering
>Temple University
>
>Ritter Hall Annex, Room 423, Philadelphia, PA 19122
>kasday@acm.org        
>(215) 204-2247 (voice)
>(800) 750-7428 (TTY)
>
>
>
-------
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org        
(215) 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Friday, 5 November 1999 15:34:54 UTC