Benjamin Hawkes-Lewis wrote:
On 21/5/09 09:02, Jim Lucas wrote:
I have been toying with the idea of doing a <table>-less layouts
involving tabular data, calendars, etc...
But, not knowing how the various types of accessibility applications
work, I am guessing that the layout to an application trying to read it
should work fairly well. Let me know if I am way off the mark with my
The responses suggesting that "even W3C" would let you use tables for
data tables are too weak.
W3C recommend you use the best possible semantic (X)HTML for your
structured content and, if you want to style it, suggest a skin or skins
for that structure with CSS. This is why "table" is the wrong tool for
grid layout and the /right/ tool for tabular data.
This isn't "semantics for the sake of semantics". Table markup implies a
series of relationships that user agents can use in two basic ways:
1) Render content appropriately to communicate tabular relationships.
For example, text browsers and browser/user stylesheets in GUI browsers
can arrange tables in rows and columns, stick borders between cells,
embolden/color header cells and captions, repeat header rows after a
page break when printing. GUI browsers can copy table markup to system
clipboards such that you can paste the table into a word processor or
spreadsheet as a table. Screen readers can read or braille the table
caption or summary when the table receives focus, and render an
individual data cell's headers when it receives content focus.
2) Provide navigational functionality. For example, popular screen
readers use table markup to give users commands to list tables on a
page, jump to the next table, move to the next row rather than the next
cell, query a cell for its headers, read row-by-row, or read
column-by-column. For example:
So replacing good data markup ( http://www.webaim.org/techniques/tables/
) with a tree of "div" elements involves a substantial loss of
functionality, and accessibility.
If for some reason, you /must/ use generic "div" elements instead of
real tabular markup, I strongly recommend you annotate them with
WAI-ARIA attributes ("grid" and related roles). Supporting clients will
expose similar structural information to assistive technology as you
would get with (X)HTML tables. WAI-ARIA has poor support compared to
bog-standard (X)HTML tables, but it should be supported by the some of
the newest browsers and screen readers (e.g. Firefox 3, IE8, and JAWS 10).
Calendar markup is a very tricky one.
But I'd certainly take advantage of (X)HTML's dedicated markup for
relationships ( tables, lists, headings, hyperlinks ) to help users
navigate the calendar and to ensure a decent presentation (even without
your CSS) is applied, rather than expect users to parse linearized "div"
Some useful discussion at:
if you are ever in doublt as to whether you are doing things correctly
or not, highlight the entire web page in question, copy it, and paste it
in to a very basic text editor. Then read from line 1 to the end, if any
of it doesn't make sense or seems misplaced, then it's been made
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php