I am tempted to say that this is a moot point. In my experience complex data
tables are inaccessible to screen reader users because they have great
difficulty forming a mental model of them. Marking them up perfectly
semantically doesn't help.

If you use 'normal' means of navigating, the table cell contents are read
sequentially. Each cell is usually understandable but you get no sense of
the structure and relationships with the column and row headings.

If you use the table navigation commands, the column and/or row headers are
read in addition to the cell contents. This provides structural information
but the user has to mentally separate the header and cell data before adding
them to their mental model. This is difficult enough with simple tables but
I don't recall even highly proficient screen reader users successfully
navigating complex tables during user testing.

What I can't say is whether any other user group derives any benefit from
the correct semantic markup of tables. Off the top of my head I can't think
of any. I also cannot think of any applications (e.g. search engines, news
scrapers etc) that programmatically access websites that would benefit from
this either.
 
Steve Green
Director
Test Partners Ltd


-----Original Message-----
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of Kat
Sent: 02 November 2009 00:19
To: wsg@webstandardsgroup.org
Subject: [WSG] Complex data tables, accessibility and XHTML Basic 1.1


Gday all,

We're all agreed that tables should only be used for tabular data, and
should be marked up properly for accessibility.


*WCAG 1.0 and 2.0 links about table accessibility and specific markup*

WCAG 1.0 Checkpoint 5.2 says "For data tables that have two or more 
logical levels of row or column headers, use markup to associate data 
cells and header cells. [Priority 1]"
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-table-structure
http://www.w3.org/TR/WCAG10-HTML-TECHS/#identifying-table-rows-columns

And in a working draft for WCAG 2.0, HTML Techniques for WCAG 2.0*, 
Section 7.5,  Identifying groups of rows: Use thead to group repeated 
table headers, tfoot for repeated table footers, and tbody for other 
groups of rows. (optional)
http://www.w3.org/TR/2003/WD-WCAG20-HTML-TECHS-20031209/#datatables_rowgroup

Section 7.6 Identifying groups of columns: Use the colgroup and col 
elements to group columns. (optional)
http://www.w3.org/TR/2003/WD-WCAG20-HTML-TECHS-20031209/#datatables_colgroup

Noting, that both are optional, under WCAG 2.0 (working draft).


*XHTML Basic 1.1*
Now that there are more and more handheld devices being used to access 
the web, I have been thinking that some websites might benefit from 
moving to a different markup: XHTML Basic 1.1, particularly if the 
majority of their user-base are on handheld devices. This way they can 
serve up something the majority of their audience can use and also allow 
access through a desk- or lap-top device.


*Questions*
XHTML Basic 1.1 does not include thead, tbody and tfoot, along with col 
and colgroup, which is mentioned under WCAG 1.0 and WCAG 2.0 for 
acessible complex data tables.
http://www.w3.org/2007/09/dtd-comparison.html

Can a complex table be accessible without these elements, or do we, as 
developers, accept the loss of accessibility (both on a practical and 
compliance level) on data tables with the advent of the mobile web**?

As much as I might like to support the argument that complex tables 
should never appear on mobiles, I'm not sure it's realistic. There may 
be a time when a complex table in XHTML Basic 1.1 is served up to both 
handheld, and desk- and lap- top devices. In that event, what can the 
developer do?

Kat

* Wow, that's a working draft from 2003, SIX years ago. Can that be true?

** Not my preferred option.


Is this too complex for a Monday morning?



*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******************************************************************



*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******************************************************************

Reply via email to