W3C home > Mailing lists > Public > public-html@w3.org > September 2008

RE: Is longdesc a good solution? (was: Acessibility of <audio> and <video>)

From: Justin James <j_james@mindspring.com>
Date: Mon, 8 Sep 2008 10:44:09 -0400
To: "'David Poehlman'" <david.poehlman@handsontechnologeyes.com>, "'Henri Sivonen'" <hsivonen@iki.fi>, "'John Foliot'" <foliot@wats.ca>
Cc: <public-html@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Message-ID: <13b301c911c1$59fe7b20$0dfb7160$@com>

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of David Poehlman
> Sent: Monday, September 08, 2008 9:53 AM
> To: Henri Sivonen; John Foliot
> Cc: public-html@w3.org; 'W3C WAI-XTECH'
> Subject: Re: Is longdesc a good solution? (was: Acessibility of <audio>
> and <video>)
> 
> One example I see is tables on the web.  There is really only one use
> for a
> table and that is for data yet, we see it being used for layout all
> over the
> place.  Why?  because it looks pretty.  Now, if you want to do
> something
> good for accessibility in html5, how about eliminating the possibility
> that
> tables will be used for anything but data?

I wish that was possible. There are three huge problems with that:

* As you've mentioned, a lot of "casual HTML authors" who learned "just
enough to be dangerous" 10 years ago and are still cranking out that code.

* Authoring tools... not of the desktop Web editor variety like Dreamweaver
and Expression Web, but of the embedded kind; cranking out tables is
programmatically simpler and more reliable than trying to produce working
CSS positioned layout, *especially* when it is code that is being embedding
into a page that the widget knows nothing about in advance.

* Programmer widgets in existing libraries, such as the J2EE components,
.Net Framework components, etc. These widgets face the same issue that the
embedded authoring tools do. They are designed to generate code that works
100% correctly 100% of the time, regardless of what the surrounding HTML
looks like or what stylesheet has been applied to the page. Wrapping the
generated code in a table to control the layout is a lot easier and a lot
more reliable than non-table methods under those circumstances.

The trend is that more and more HTML is automatically generated and/or
created as a "side effect" of other work, compared to hand-authored HTML.
Indeed, hand-authored HTML is (unprovable, but quite obvious unless you live
in a secluded enclave of HTML authors in the wilderness) becoming rather
rare. The closest most pages now get to being "hand authored" is that
someone hand-authored a template for some sort of system (CMS, blog, etc.)
and so even on pages with a hand-authored skeleton, it's going to be
littered with tables from the widgets.

So any good system of eliminating tables from anything but their intended
task needs to address these core problems. I would suggest that an EXCELLENT
start for a solution, would be to get the CSS folks to provide some sort of
system (no clue what it would be like!) to essentially "reboot" the styling
of a container, and allow it to function, more or less, as a sub-document.
Something like:

<page>
<div>Content</div>
<div>More content</div>)
<div>Even more content
<div style="reboot" stylesheet="embedded_widget.css">Widget with its own
stylesheet</div>
</div>
</page>

Without some sort of system like that, I would tend to believe that widgets
and other generated code will always be cranking out tables, it's the only
way (currently) for them to be as self-contained as possible.

J.Ja
Received on Monday, 8 September 2008 14:54:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:23 GMT