compliance and layout tables revisited

Andi, this is an interesting issue.  Can you make sure it is logged as an
issue for WCAG 2.0 .

I've copied the issue to the editor for WCAG 1.0 so that the errata can
address it as a technical error in 1.0

3.3 says to use CSS for layout, while 5.5 allows tables for layout when
they make sense linearized.  Both are priority 2 and conflicting.

The 3.3 *layout part* could be eliminated or combined with 5.5 because
whether it is CSS or table, both need to make sense when linearized - that
is the accessibility requirement - not which technology is used to do the
layout.  For example, DIV's with layout style ordered incorrectly in the
source can be just as confusing as layout tables used incorrectly.  I think
the working group can see this as an errata.

I have the same opinion about whether FONT tag is used or the font
properties in CSS,  the accessibility point is not whether one uses CSS or
deprecated html, but that the structure or semantics is available from the
text being styled.  3.5 Heading, 3.6 Lists, and 3.7 Quotations are covered.
So the real meaning in 3.3 is to use correctly use presentation properties.
And the techniques can be to correctly use the old FONT tag, or to
correctly use the CSS properties, or to correctly use any other
technologies features for presentation - which will fit nicely in the WCAG
2.0 principles orientation.

Regards,
Phill Jenkins
IBM Research Division - Accessibility Center
11501 Burnet Rd,  Austin TX  78758    http://www.ibm.com/able

---------------------- Forwarded by Phill Jenkins/Austin/IBM on 05/08/2002
10:53 AM ---------------------------

"Michelle Podd" <mpodd@iqnetcom.com>@w3.org on 05/07/2002 11:26:15 AM

Sent by:    w3c-wai-ig-request@w3.org


To:    "WAI \(E-mail\)" <w3c-wai-ig@w3.org>
cc:
Subject:    compliance and layout tables revisited




I've been reading the "compliance and html  validation" thread with
interest as I've had similar questions.

The people involved in the discussion seemed to  have settled on the fact
that if you use tables for layout, your page cannot  meet Priority 2 WAI
standards. Is that correct?

This is a snippet from the 1.0 Guidelines:  <snippet>

11 Layout, positioning, layering, and  alignment

Checkpoints in this section:

   3.3 Use style  sheets to control layout and presentation. [Priority 2]
   5.3  Do not use tables for layout unless the table makes sense when
   linearized.  Otherwise, if the table does not make sense, provide an
   alternative equivalent  (which may be a linearized version).
   [Priority 2] .

Layout, positioning, layering, and alignment should be done through style
sheets (notably by using CSS floats and absolute positioning): ...

</snippet>

It seems as if checkpoint 5.3 is saying you can use  layout tables. For
instance, if I use layout tables for a form where I have 2  columns (the
left holds the field name and the right holds the form control),  that
would make sense when linearized.  If I have a nav bar that goes
horizontally across the top of my web page made up of a table with several
images in it, that would make sense when linearized.

Are these two points contradictory? Is it true that  if I don't only use
CSS to layout my page that I can't say my page conforms to  Priority 2
requirements?

Denise also brought up another question related to  html validation that
I'd like to clarify. My particular problem is that I am  using a graphical
image as a button in a form. Here is the code:

<input TYPE="Image"  SRC="images/buttons/update.gif" border="0" VALUE
="Update Basket" ALT="if you  changed a quantity, Update Basket">

border="0" doesn't validate for the html 4.01  transitional doctype (the
most lenient) on the input tag yet if I take it  out, a border shows up
around the image in some browsers.

Joe's answer to that was (and thanks Joe, as you were  the only one to
provide an answer):

"Your only choice is to use a browser fork and serve  different HTML
to different browsers, only some of which will  validate."

That seems very extreme to get rid of an image  border. My question is, if
there really is no other way to remove the border and  still validate, how
far do we, as web developers have to go to be able to  say our sites meet
certain accessibility standards? Does the border element in  an input tag
make my site (or that particular part of the page) inaccessible?  No, it
doesn't. I'd love to have all the little icons on my site that tell
people we've made efforts to provide an accessible  website however I can't
see serving up different pages for different  browsers for things that
don't make any difference to the accessibility of my  page anyway. Any
thoughts or other solutions to the  validation problem?

partially asking and partially venting,

Michelle Podd, Web Designer

Received on Wednesday, 8 May 2002 12:40:54 UTC