On Thu, May 21, 2009 at 12:10 PM, tedd <tedd.sperling@xxxxxxxxx> 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 <bhawkeslewis@xxxxxxxxxxxxxx> > 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: > > http://www.w3.org/TR/wai-aria/#presentation 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 (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
