[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 ***
Re: [WSG] Complex data tables, accessibility and XHTML Basic 1.1
Steve Green wrote: 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. Thanks for that Steve! :) Then would the answer, perhaps, be to give a small succinct paragraph about the tabular data, with the most important points (if they exist), and perhaps a link to contact details if the user wanted to know more? And not worry about thead, tfoot, tbody, col, colgroup, etc? Would that be an acceptable accessibility alternative? Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Complex data tables, accessibility and XHTML Basic 1.1
-Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Kat Sent: 02 November 2009 01:35 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Complex data tables, accessibility and XHTML Basic 1.1 Steve Green wrote: 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. Thanks for that Steve! :) Then would the answer, perhaps, be to give a small succinct paragraph about the tabular data, with the most important points (if they exist), and perhaps a link to contact details if the user wanted to know more? And not worry about thead, tfoot, tbody, col, colgroup, etc? Would that be an acceptable accessibility alternative? Kat It depends on what your objectives are. Many of my clients have a contractual obligation to meet the letter of the WCAG, in which case using the correct semantics meets their objectives even though it results in a poor user experience. The same would be the case if you were concerned about the tables being programmatic accessible. If your objective is legal compliance, providing the information by alternative means is certainly an option, and the provision of contact details may well be sufficient depending on the prevailing legal environment. You would need to put in place a procedure to deal with requests for help, and there would likely be a cost - might it just be cheaper to fix the tables? If your objective is a good user experience, don't use complex tables. Steve *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Complex data tables, accessibility and XHTML Basic 1.1
Hi Kat, That really depends - without user research it's hard to know what conclusions about the data are relevant and of interest to people consuming that data; plus if the purpose is for people to draw their own conclusions (hence why you're *providing *all that data) then it doesn't make sense to bias it with pre-formed conclusions. If you *have* to use tabulated data then that's a challenge, sure, but I suggest going back over the business case for presenting the data and seeing if there's some other way the *information* can be presented. Looks at alternative presentation formats such as filtering - but as I said it depends because datasets hidden behind a search/filter form can be frustrating to users who may want to browse the matrix to figure out what they want if they're unfamiliar with the data model or want to identify trends and work backwards. Comes down to user goals. Nathanael Boehm Freelance web user interaction designer UX · IxD · UI design · Prototyping · HTML · CSS · JS · Usability · Accessibility · Social media Imagine Innovation · UXnet Canberra · OpenAustralia · BarCampCanberra www.purecaffeine.com http://www.purecaffeine.com/about/ Canberra, Australia 0409 288 464 On Mon, Nov 2, 2009 at 11:34 AM, Kat k...@t-tec.com.au wrote: Steve Green wrote: 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. Thanks for that Steve! :) Then would the answer, perhaps, be to give a small succinct paragraph about the tabular data, with the most important points (if they exist), and perhaps a link to contact details if the user wanted to know more? And not worry about thead, tfoot, tbody, col, colgroup, etc? Would that be an acceptable accessibility alternative? Kat *** 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 ***
