W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 1998

RE: Can we really deprecate tables?

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Mon, 24 Aug 1998 09:21:01 -0500
Message-Id: <199808241423.JAA00818@staff1.cso.uiuc.edu>
To: <po@trace.wisc.edu>, <A.Flavell@physics.gla.ac.uk>, "GL - WAI Guidelines WG (E-mail)" <w3c-wai-gl@w3.org>
I agree with Gregg, we need to get HTML authors to take the page author
guidelines seriously and guide them into thinking and learning more about
accessibility, especially CSS for formatting and positioning.  If the
guidelines say tables are forbidden, I think many authors will discount the
use of the guidelines.  I think "whenever and whereever" statement on CSS
needs to be expanded to include more detail and guidance, but that may be a
job for education and outreach.  

I think another critical aspect of the equation is when will tools support
the guidelines, most authors understand little about the underlying HTML.
So tools will be critical.
Jon


At 12:42 AM 8/22/98 -0500, Gregg Vanderheiden wrote:
>The question for this particular topic isn't when people with _disabilities_
>will have browsers that support CSS.   The question to web authors is when
>_the vast majority of all of their intended viewers_ will have CSS capable
>browsers.  They don't want to switch away from tables for layout (and use
>CSS) until the vast majority of ALL their users will see their page the way
>the authors want them to.  So in this particular case, it isn't a matter of
>what people with disabilities can or cannot do.  It is a matter or function
>of what the vast majority of their viewers do or do not do,  or have or do
>not have.    I believe it will be some time before the vast majority of
>users have CSS enabled viewers.   How long - I don't know.   Hopefully not
>too awfully long.  But some people and systems change slowly.  (For
>example - I hear there are government agencies that do not allow HTML 4.0 to
>be used.)
>
>So the guidelines are written to say Use style sheets whenever and wherever
>you can…. But if you cant you can use tables and bit mapped text but be sure
>to do the following if you do.   It is in shorthand in the guidelines and
>will be in more detail in the techniques doc.
>
>We believe that to say that you must use CSS and not allow that the use of
>tables is ok for awhile is to not be realistic.  And the guidelines must be
>progress and aggressive but still realistic - or I feel we will achieve less
>rather than more.
>
>Thoughts, comments and suggested wordings are all solicited.
>
>Gregg
>
>
>
>-- ------------------------------
>Gregg C Vanderheiden Ph.D.
>Professor - Human Factors
>Dept of Ind. Engr. - U of Wis.
>Director - Trace R & D Center
>Gv@trace.wisc.edu, http://trace.wisc.edu/
>FAX 608/262-8848
>For a list of our listserves send "lists" to listproc@trace.wisc.edu
>
>-----Original Message-----
>From:	w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
>Of Alan J. Flavell
>Sent:	Tuesday, August 11, 1998 6:24 AM
>To:	Dobson, James
>Cc:	w3c-wai-gl@w3.org
>Subject:	RE: Can we really deprecate tables?
>
>
>Excuse me, but there seems to be some misunderstanding between us
>here.  Let me express directly the point that I believe I am
>addressing here, just to be sure that we aren't arguing along
>different lines.
>
>As I understood it, you were saying that the migration from "tables
>for layout" to style sheet layout control should be deferred until
>fully CSS-capable browsers were available to _disabled_ users (in
>this context we're thinking specifically of visual impairment.)
>
>I don't see why this is either necessary or appropriate.  It seems to
>me that the style sheets that are going to be supplied by the vast
>majority of web page authors will be targetted at (excuse me) "normal"
>users and browsing situations, and this presentation is more likely to
>get in the way of accessibility to unusual browsing situations than to
>help it.  For the most part I believe that readers in unusual browsing
>situations will want to be turning off or overriding the presentation
>suggestions in the supplied style sheet, and imposing their own
>presentation.  This can be done adequately with even quite old
>browsers, via their configuration options (even better in browsers
>like Opera, that offer the reader a wide choice of fonts, colours
>and magnifications).
>
>I have carefully read your reply and I honestly still am unable to
>understand why you consider that this migration needs to wait for
>_visually impaired_ readers to have style-sheet-capable browsers.
>Quite the opposite:  your argument reinforces the idea that immediate
>migration is especially advantageous to visually impaired readers, and
>the reason that the migration is being resisted by many is the fact
>that it's potentially deleterious to _mainstream_ browsing situations
>that don't yet support CSS.
>
>On Tue, 11 Aug 1998, Dobson, James wrote:
>
>> A development on RNIB's website allows visually impaired user's to specify
>a
>> style sheet to access RNIB's webpage in there own font, colour and size
>etc.
>
>I don't for a moment want to say anything against that, but surely
>visually impaired readers want to access the whole range of pages that
>are on the WWW, they don't want to be restricted to the ones that have
>been especially tailored for their needs.
>
>> As you may well know the term visually impaired covers a lot of eye
>> impairments, and each person may see slightly more or less. This means
>that
>> allowing the user to have as much control over what is displayed is very
>> important.
>
>Certainly: that was my whole point.  And that's the reason why an
>author-provided style sheet, no matter how carefully designed, and no
>matter how beneficial for _some_ readers, is inevitably going to make
>matters worse for some subset of readers who have different
>requirements.
>
>> We have all seen the different ways Netscape and Internet Explorer handle
>> CSS.
>
>If it's a problem, then turn it off.
>
>> I was not aware that you can "turn off" CSS in these browsers (tell me
>> different!!),
>
>I am frankly astonished that you are unaware of this.
>In CSS1, for example, it states:
>
>  This strategy gives author's style sheets considerably higher weight
>  than those of the reader.  It is therefore important that the reader
>  has the ability to turn off the influence of a certain style sheet,
>  e.g. through a pull-down menu.
>
>I think that's tantamount to a mandatory requirement on CSS-capable
>browsers to offer the ability to turn style sheets off.
>
>As another mail has just pointed out, there are some problems with
>turning it off in MSIE4, but that seems to mean that having a non-CSS
>capable (e.g "old")  browser can be beneficial in some situations;
>that doesn't seem to me to support your thesis that migrating from
>table-for-layout to CSS needs to wait for CSS-capable browsers (if
>anything, it supports the opposite conclusion, no?).
>
>> I have noticed that you can specify a user CSS file in IE
>
>This could be an additional convenience, but I don't see how it is a
>necessary _before_ promoting a migration from tables-for-layout to CSS
>layout.
>
>> When using CSS for structural presentation, if a browser ignores the CSS
>> information it will display it all as one piece of information after
>> another. If the HTML file was not designed properly then you could have
>> information in locations that are not appropriate.
>
>CSS is not intended to be used for conveying structural information,
>but for suggesting an appropriate presentation of the content and
>structure: but the suggestion can only be appropriate for a certain
>range of presentation situations, and is going to be useless or even
>counter-productive some other ranges of presentation situation (and,
>as I said before, this relates to shortcomings of browser platforms
>just as much as it relates to physical impairments that the reader
>might have).
>
>A properly built HTML/CSS document will still present its content when
>the CSS is ignored, as indeed it must be in some situations (colour
>information will be useless in a monochrome browsing situation, and
>font suggestions cannot usefully be implemented in a speaking browser,
>to take just two examples).
>
>> This would be down to
>> good design, but surely a browser can be programmed with the ability to
>> ignore or change table tagging if the user requires it?
>
>This seems to be suggesting a hack to work around the shortcomings of
>another hack, when a properly engineered solution is already there.
>
>I think I better shut up now and let other people have their say.
>
>best regards
> 
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess
Received on Monday, 24 August 1998 10:23:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:46:58 GMT