Re: [PHP] Re: -less layouts; Ideas welcome

Thu, 21 May 2009 12:34:59 -0700

On Thu, May 21, 2009 at 12:10 PM, tedd <> wrote:
> Could you be certain that your algorithm would figure out which way it needs
> to present the text to a blind person?

My own experience browsing the web with Lynx (which for the most part,
tends to ignore table layout, giving you the content of table cells in
source order) suggests that order doesn't end up being a significant
issue. The common layouts tend to read surprising well in source
order. Navigation is usually at the top or the left, so you encounter
it quickly. If there's any problem, most of the time it's that the
page author has done something hideous with a lot of images with no
alt text or abuse of HTML entitites, or part of the navigation
structure is only accessible via javascript or flash or something like
that... all separate issues from repurposing tabular markup.

And when there *is* some kind of a layout issue, most of the time it's
easy to adapt as a human reader by searching/scanning (sometimes
easier than if you're looking at a bad visual layout). The tools that
enhance accessibility on a page in these respects really don't have a
lot to do with whether there's tabular markup -- if you want to enable
easy access to page navigation, you can add semantic information about
that regardless. In fact, that information is quite likely more
important and less prevalent than what you end up with even most
CSS-positioned sites, given that the vast majority of them simply
provide stylesheets for the purposes of... visual layout, and what
you're left with when a screen reader ignores them is linear
source-ordered elements.

None of this is to say that CSS can't be very useful in addressing
this problem (and other problems), or that there aren't some problems
with tabular markup. The presentation example you mentioned is
actually going to be an issue with even real tabular data without some
care taken in the markup. And I don't want to go back to coding 1999
markup for 1999 browsers. Mostly my point is that the problem with
using tables is a bit more limited in size than it's often made out to
be, there are other ways of dealing with the accessibility and
semanticity issues involved, some of them potentially more effective.
And for some cases, table layouts just work better. I think we'd be
better off with a wide variety of professionals who can balance these
different issues than with a  "tables considered harmful" summary.

> Now compound that with cells holding images,
> place-holders, empty cells and cells with navigation elements,
> flash, videos, and such -- and you might have a better appreciation
> as to the problem screen readers face.

These are actually some of the heuristic markers I believe some
browsers actually use (and if they don't, they certainly could). If
you have a table whose cells largely contain highly mixed markup,
largely presentational elements, no alternative data, chances are
pretty good that it isn't tabular data. And...

Benjamin Hawkes-Lewis <>
> WCAG 1.0 ... explained how /authors/ could distinguish between layout
> tables and data tables:
> 1) When writing a presentational table, stick to the elements "table", "tr",
> "td". Do not use the "headers", "scope", "axis", or "summary" attributes.
> Make sure layout tables make sense when linearized.
> 2) When writing a data table, add the elements "th", "thead", "tbody",
> "tfoot", "caption", and "col" and the attributes "headers", "scope", "axis",
> and "summary" wherever appropriate.

Exactly. These are great markers for distinguishing between where
authors were using table markup semantically or presentationally. I
think in practice there are probably many others available.

> Fast forward a decade, and authors are getting another tool in our toolbox,
> not a million miles away from your 'class="layout"'. I don't think it's very
> well specified yet, but:

I'm actually amazed... this is very nearly what I proposed in some
discussions back in 2004. I eventually shifted to class="layout"
because it had some other practical benefits and everybody I talked to
seemed to feel cluttering up the attribute space with yet another item
was wrong (on top of this sortof general malaise about repurposed
table markup), especially when considering how much semantic mileage
you can get out of class attributes. I'd be totally happy to see
anything like it adopted, though, and as I said before, think it'd
push the semantic web forward faster than waiting for everyone to come
around to doing things one blessed way.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to