|Get in Touch|
by Jim Byrne, The Making Connections Unit, Scotland's First Comphrensive Web Accessibility Service (established1996).
In this article you will find:
I know it is good to create accessible Websites and I know that this means writing standards based HTML, however there is a question regarding creating tables; whether the HTML TABLE element should be (mis)used to lay out Web pages? You can have accessible web pages and use the TABLE element and feel virtuous but this means limited design options. Or I could decide to forget about structure and go with presentation - if I am a smart designer, I should make some usability gains for the majority of visitors to my site.
It's been a difficult dilemma but I think I have come to a decision - and yes - at least until CSS for layout becomes less troublesome - the TABLE tag is my friend. Control of layout is important - but whether I use CSS, tables, or avoid both, as yet, there is no completely satisfactory solution. Cascading Style Sheets are an option but current use of CSS merely substitutes 'CSS hacks' for 'table hacks', in an attempt to work around Web browser bugs and incompatibilities. It is indicative of where we are with CSS for layout that the World Wide Web Consortium (W3c), who publish the 'official' Web Accessibility Gudelines, still use tables to layout the design of their Web pages.
The W3c Web Accessibility Guidelines recognise that designers will continue to use table for layout - and so include information about how they can be implemented in the most accessible way. Designers are not going to immediately stop using tables for layout; mainly due to the fact that this is the default behavior of most WYSWYG (what you see is what you get) Web design packages and; CSS for layout is so difficult to implement successfully. However, it is not good enough just to ignore the issue, or say that it is wrong to use them. A more sensible approach is to ensure that the resulting Web pages are accessible.
But before I go rushing forth to use this great layout power, let's linger a moment to see what I will be missing if anything from my old 'no tables for layout ' policy:
Apart from the home page this Website (http://www.mcu.org.uk) does not use tables for layout - as a result I frequently get e-mails asking how I managed to design a Web site that loads so quickly (honestly!). For the same reason Philip Greenspun in his 'must read' book 'Philip and Alex Guide to Web Publishing' warns against enclosing your entire page in a table (I think that was what he said - it's a big book and I couldn't find that bit when I looked - but he does mention it again in this article What can we learn from Jakob Nielsen?).
This speed problem arises because all the bits of a Web page within the table have to be in place before the table itself can be displayed on the screen. Certainly this has been the case in Microsoft Explorer. So, if there are lots of tables within tables and lots of graphics within those tables - and everything in the page is enclosed within one big daddy of a table - you are going to have to wait a while to see anything on your computer screen (sound familiar?). To be fair I don't think Netscape Navigator works this way, although the market share for Netscape seems to have shrunk a good bit lately.
So, if speed is an issue, and when is it not? using tables to layout your pages will slow up the display of your Web pages.
Most pages without tables tend to be single column with navigation at the top or bottom - this is good for people who are blind or have a visual impairment and are using older style screen readers to access the page. Checkpoint 10.3 in the Web Accessibility Guidelines - which is about implementing interim solutions hints at why this might be the case,
“Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (in the current page or some other) for all tables that lay out text in parallel, word wrapped columns. [Priority 3]”
Many of the newer screen readers can deal with side by side columns of text (because they take their cue from the actual HTML), but older screen readers just read from left to right across the page, so anything that is on the same, row but on a different column, will be read as a single sentence. Borrowing from the example in the guidelines to illustrate, but giving it my own twist, here is an example of two columns of text that may appear on a Web page:
Oh you canny shove your granny aff the bus,
ye canny shove yer granny aff the bus,
ye canny shove yer granny
cause she's yer mammy's mammy,
oh ye canny shove yer granny aff the bus.
|Step we gaily on we go
Heel for heel and toe for toe
Arm in arm and row on row
All for Mairi's wedding.
This will be read by older style screen readers in the following way:
Oh you canny shove your granny aff the bus, Step we gaily on we go, ye canny shove yer granny aff the bus, Heel for heel and toe for toe ye canny shove yer granny, Arm in arm and row on row
and so on..
(Not good, but - it may have one saving grace - perhaps I can use this technique the next time I am need to write some lyrics for a new song. I think David Bowie used a similar 'cut up' technique in some of his early work - he in turn got the idea from the 'Beat' writer William Burroughs).
If I was to follow the HTML standards rigorously I would be using style sheets for page layout exclusively - and there are excellent reasons for doing so:
Unfortunately today the phrase 'in theory' is still relevant in relation to the above advantages. The combination of legacy browsers that implement bits of the standards, but not others, and new browsers that interpret the standards in different ways, mean that the reality does not yet match up with the theory.
In summary, no tables for layout mean greater speed and greater accessibility for people who are using screen readers to access the Web. Pretty powerful arguments for continuing to write nice structured markup language in the way that it was intended - and avoid that murky feeling that you get when you know you have written some less than pristine HTML.
To help us answer this question we need to ask the rather obvious question - is the ability to layout content in any other way than as a single column important? Or to put it another way, should we have Web 'designers' or do we just need people who can efficiently manage Web documents?
Of course, the answer is yes, design is important and good designers will always be needed, and there should be no need to make a choice between making a page look good or making it accessible. Contrary to the common view of the markup purists - content and presentation are not entirely separate. The design of a Web page: the layout; colours; use of empty space; typography used etc impact upon the accessibility (in a broad sense) of that content. Design and layout are not necessarily secondary to understanding - so we need to acknowledge the importance of design from the point of view of building accessible Websites (and to boot - clients think the visual design is the most important aspect of their Website - rightly or wrongly).
It is only the history of HTML layout limitations that makes us think that we have to have one or the other. If Tim Berners Lee had had just one more inspired thought back in 1990 and 'invented' a Web that included both HTML and style sheets - would we still be having these discussions? Of course not - we know design is important - and so is standards based markup. With a mature combination of CSS and XHTML from the start by now we would be used to the idea that we could produce an infinite number of designs from the same markup - each design catering to a different audience.Being able to layout the information on a Web page is important for at least two reasons:
There are two things you could say to me for daring to suggest that there are accessible ways you can use tables for layout:
In response to the first I say that I understand fully that separating presentation and structure is important - see 'This HTML Kills' written in 1999 (which was subsequently published on A list apart http://www.alistapart.com). I am an advocate of separating structure from presentation - but I do not think this is as clear cut an issue as it may at first seem. It is important that content be accessible - in the broadest sense - and you can't fully divorce content from the presentation of that content. The way you present information is an important part of the communication process, and that includes how information is presented on a computer screen. Today, both those commissioning Websites, and those consuming, them are likely to be using Web browsers on desktop machines and we cannot ignore this group any more than we can ignore the smaller market for consumption of Web pages by other user agents.
To the second question I say, ok that's fine if you have never seen the type of layout, which I suggested could increase usability - so find the one that, as far as you are concerned, is the most consistently used on the Web - and copy it for your own site. Do this and the usability of your site is likely to increase. I think you will find that to copy your selected layout you are likely to need the help of TABLE or CSS layout features.
But, given that we agree that design is important - we also need to know if we should be using Cascading Style Sheets for layout today. Can you use current implementations of CSS, (on current and past browsers) to layout pages in a way that increases usability, accessibility and provides design flexibility?
The Web Standards Group (http://www.webstandards.org/index0901.html) think so and make a good case for designers to 'go the whole hog' and ensure that you only use standard HTML in your pages. I fully support the idea of using cascading Style Sheets for page layout - but they are not ready for full scale implementation yet. Inconsistent support of the relevant style sheet properties can result in pages that are more inaccessible than those using tables for layout. It is not the browsers or 'user agents' that don't support style sheets that are the problem - that's fine - these browsers will still get the content but it will be presented differently. The problems are the browsers that do support style sheets but are riddled with bugs and improper implementation of the standards. These are the ones that make pages inaccessible with graphics obscuring text and columns floating on top of each other. See Little Shop of CSS Horrors (http://haughey.com/csshorrors/) for examples of what I am talking about.
Even the latest and greatest Web browsers (e.g. Internet Explorer, Netscape, Opera, iCab) do not yet fully support Web standard consistently. Using Style sheets for more that the simplest layout is not yet feasible for everyone - unless you are willing to spend the time learning about all the workarounds required. If you take the time to test every browser, on every hardware platform, then I support you fully in your desire to get out of the tables habit (perhaps we should all join the TLA, 'Tables for Layout Anonymous' - just take one day - or is it one browser - at a time).
I support the move towards CSS and standards based HTML (ideally XHTML). However, I know that most designers are using tools that use tables as the default layout device - so we need to acknowledge that, and give designers information about how to make those tables as accessible as possible.
Are you throwing your hands up in horror and saying, 'Jim has abandoned his accessibility principles'. You may think so, but I will spend the next part of this article explaining how you make layout tables accessible for all your visitors, including those who are using older screen readers. In so doing I hope to rescue my accessible Web design credibility. At the moment - and I know no-one will thank me for saying it - but it is probably more likely - and easier - for a Web developer to create an accessible Web page using tables than it is for that same developer to create an accessible Web page using Cascading Style Sheets. To put it simply you need to know more to use style sheets correctly. There is a lot of information available about making tables accessible but very little information about ensuring your style sheets don't fall down when they meet the bugs in the many legacy browsers, which are still in use today.
First rule of creating accessible layout tables on the Web: make sure that when they 'unravel' in browsers that do not support tables that the information in them still makes sense and is in the right order. Or as the WAI states: make tables that still make sense after 'linearization'. In browsers that do not support tables the information is read as a series of paragraphs starting from the top left cell in the table, moving right into each cell in turn - displaying the information on the page as it finds it. Once the first row is exhausted the content in the second row is extracted in the same way - and so on down the page. It's very simple - but here's an example for those who are 'visual learners' - giving the order that cells will be read.
One good tool you can use that gives you a graphical display of the order that the cells in your Web page will be displayed can be found at : http://www.temple.edu/inst_disabilities/piat/wave/ The tool is called 'WAVE' and it numbers each table cell in the order that it will be read by a browser. WAVE has many other useful features to check the accessibility of your Website. Another way to check that your tables are accessible is to view the page using a text based browser such as Lynx, which can be found at http://lynx.browser.org/. You can find the Mac version at http://www.lirmm.fr/~gutkneco/maclynx/.
Checkpoint 3.4 of the WAI Content Authoring Guidelines states:
3.4 Use relative rather than absolute units for markup language attribute values and style sheets property values [Priority 2]. For example, in CSS, use 'em' or percentage lengths rather than 'pt' or 'cm', which are absolute units. If absolute units are used, validate that the rendered content is usable (refer to the section on validation).
Why would we want to do this? Well the idea that it is not possible to predict how the end user will be viewing or accessing your Webpage; they may be viewing the page on a TV or a palm device or a internet enable games console. Take just one variable in the equation - screen size. We don't know when designing a Web page the size or the resolution of the end user's screen. If this is the case it makes little sense to specify a layout so many pixels wide by so many pixels high - better to provide percentage widths for elements. Do it this way and the entire pages will still be viewable, whatever the screen size. (I will deal more fully with the issues of designing for different sized monitors in another article).With traditional print design the designer knows everything about how the final design will look; what size it will be, what the colours will look like, how the design will be viewed, what the typography will look like etc. On the Web this is not the case - all you can do is try to design with flexibility in mind - your designs should 'degrade' gracefully and still be accessible on a multitude of Web connected devices.
There are areas where usability and good accessible Web design practice can conflict. For example, research reveals that the optimal line length for comfortable reading is about 10 to 12 words. With our relative sizes approach, there is very little we can do to accommodate this fact.
Having recommended earlier that it might be a good idea to use a navigation bar, sitting to the left of each page (and you know I don't want to cramp your style so feel free to ignore my advice ). I will and so will Jeffrey Zeldman) however, bear in mind this can create problems for people using screen readers. Earlier I described the order in which layout tables are read - and that means if the navigation is on the left - you are likely to come across lots of links on every page of the site. This being the case the visitor to your site will have to tab their way through a great many links on each page before they arrive at the interesting bits, i.e actual page content.
Screen readers can't easily give an overview of a Web page to allow the listener to jump straight into the bits of text that are of interest (I tell lies here - some of the newer audio browsers can, but only if the page uses proper structural markup). This is a major time waster for blind or visually impaired users who are using these access tools. How do we get over this problem. Jim Thatcher in his excellent Web site http://www.JimThatcher.com (set up to help those wanting to comply with the Section 508 in America) suggests several imaginative ways to beat the navigation jam. They are all worthy of attention, but the one I prefer to use is a simple link to jump to the main content of the page. Here is an example. On the Website promoting all that is good about the West End of Glasgow run by my wife Pat the navigation can be found on a left bar on every page. At the top of the page I have placed the following HTML code:
<A href="#maintext"><img src="http://www.glasgowwestend.co.uk/images/spacepixels.gif" height="2" width="2" hspace="0" vspace="0" alt="Skip over navigation bar" border="0"></A>
This adds an image with the label "Skip over navigation bar" - invisible to most visitors - unless they are surfing with graphics turned off, or surfing using a text only browser. The image links to an anchor further down the page - just before the start of the main bodytext. This is set with the following code:
Using this technique has no affect on the layout of the page when viewed in a graphical browser, but here is how it looks on MacLynx:
Another useful accessibility technique for tables is to provide some text within the TABLE element that summarises the contents of the table. This is done using the summary attribute. It is probably most useful with data tables, where the relationships between the table cells can be complex, but it is also useful for layout tables. An example of a summary would be:
<TABLE summary="This table is for layout only. The left-hand column contains the navigation bar and the right hand column contains the main text for the page">
For complex data tables the summary attribute can be used to provide a text version of the actual content of the table (although for tables with a lot of content this may be impractical), or to indicate that a link to a text version can be found before, or after, the table.
The following tips come courtesy of the Idyll Mountain Internet Website.
If all else fails and you cannot ensure that your table is accessible to people using text only browsers, or those using speech technology, you should provide an alternative text only version of the information provided in the table. Add a link to your alternative version before the start of your layout table - not within the table itself. You might think this is self explanatory - but I have seen this 'technique', of playing the link to the accessible text version inside the 'inaccessible' table, many times).
Netscape 1.1. (released in the mid 90's) was the first browser to recognise tables. Some older non-table-aware browsers cannot present table based content in a meaningful way. The only way to accommodate people using these older browsers is to provide a single column alternative. For all the reasons I mentioned earlier, I am reluctant to advocate the banning of tables for layout - despite the preceding fact - and despite the knowledge that their use goes against current HTML standards.
Ok that's enough about creating accessible tables for layout - time to look at the correct use of the TABLE element, i.e for tabular information such as bus timetable, tv listings, survey results etc. This is the type of structured content that the table element was originally designed for. These data tables generally have headings along the top or down the side, or both.
The first step towards making data tables accessible is to use existing tags such as TH, TD and new HTML 4 tags such as CAPTION and SUMMARY correctly. When used as intended these tags will provide valuable meta information about your table. You should use the following tags to indicate the type of content contained with a table cell:
The summary attribute can also be used to provide a verbose description of the purpose of the table - to help someone who is using a voice or Braille browser. It can also be used to help explain the information within a table if it is of a particularly complex nature. I have seen examples of the summary attribute being used to re-state the entire contents of a table - as an alternative to providing a link to a single column version on another page.
Here is a simple example:
Here is what the HTML looks like:
The summary attribute is not visible to those using standard GUI (Graphical User Interface) Web browsers - but can be used by assistive technologies such as screen and braille readers.
It is probably not a good idea to put a summary attribute into every table in your layout as many layouts consist of lots of tables within tables. If you are feeling queasy about the fact that your Web page will not pass the 'Bobby' test because you have not put summaries in all of your tables (apart from the main table) it might be a better idea to add a short summary such as 'Layout table' or put the summary attribute in but fill it with a space character.
Headers are by default center aligned within table cells. I am not sure if this is why so many people ignore the TH tag and use the TD tag for their headers instead - but if that is the case it is worth noting that aligning headers is a simple matter. Ideally Cascading Style Sheets (CSS) should be used to align headings left or right - but the align attribute also works with the TH element, e.g.
<TH align="left" style="text-align: left">Jim</TH>
I have used CSS within the element to illustrate this point - but it is better to set the style attributes in an external style sheet or one within the header of the document. This ensures that users with their own style sheet will be able to over-ride your preferences.
If you are using style sheets to set the attributes for your table you can still leave in the old style attributes. Your style sheet will override the values of the table attributes as will the style sheet used by a visitor to your site. The older style attributes should ensure that your table still looks good in the browsers that do not support style sheets.
On a related note, do not use TH as a way of making text within a normal data cell bold and centered - use TD and provide appropriate presentation markup - preferably using a style sheet.
So far, in relation to data tables, everything has been straightforward; nothing mentioned so far to strain your cerebral cortex too much. The accessibility problems really begin when we are dealing with more complex tables, those with many rows and columns. The critical issue is how we ensure that the relationships between the table headers and the table data remains clear to someone using a simple screen reader or braille display.
If you are a sighted user this is a fairly simple procedure; you look at the header and scan down the column - or along the row - to read off the data associated with that header. Having said that, as someone who occasionally attempts to teach students statistics, I have noticed that even for sighted users interpreting tables is not always a simple exercise - but we will convieniently ignore that fact for the moment.
As we now know access technologies such as screen readers or braille displays tend to read the data in tables a row at a time, left to right across the page. In a table with many columns and many rows this can present a major problem, i.e. trying to remember which header matches up with which particular piece of data. Once you go beyond the first couple of rows - this can become extremely difficult.
Here is an example of a table showing Cascading Style Sheet bugs in Internet Explorer 5x compiled by CSS Pointers Group at http://css.nu/pointers/bugs.html. The original table at has 13 rows - I have just extracted the first five rows for illustrative purposes.
|CSS Property/ Problem||Description||Workaround||Notes/Footnotes|
|absolute/relative positioning||absolute child loses position||set the width property of the parent element||W demo|
|Classes set as number (i.e. P.1)||recognized due to error-recovery||Illegal syntax; don't use||W95, NT (6)|
|color||f0f0f0 rendered||illegal syntax; include the required '#'||W95,NT|
|width on body is ignored||ignored||use width on DIV instead||W95, NT|
Try this exercise - hide the column headers in the table above, by placing a ruler or piece of paper over them - and gradually work your way down the table reading out the contents of each cell. If you are anything like me you will begin to feel anxious about what each cells represents. As a sighted person I can keep glancing up the column to reassure myself of the nature of the information I am reading. If I am using a screen reader or a braille display this is not an option open to me.
To help with this problem HTML 4 provides new attributes; 'id', 'headers and 'scope'.
By giving each table heading a unique label (using the 'id' attribute) - and then associating each of the data cells with that label, using the 'header' attribute, new Web browsers can give appropriate feedback for those using assistive technologies.
An example should make this clearer: Here is how the HTML looks for the above table using the 'id' attribute in the headers and the 'header' attribute in each of the data cells.<TABLE border="1" summary="Workarounds for CSS bugs with Internet Explorer 5x, (W=Win '95 M=Mac)" cellpadding="10">
A screen reader will read out the first data row as follows:
CSS Property/ Problem: absolute/relative,And the second row:
Description: absolute child loses position,
Workaround: set the width property of the parent element,
Notes/Footnotes: W demo
CSS Property/ Problem: Classes set as number (i.e. P.1),
Description: recognized due to error-recovery,
Workaround: Illegal syntax; don't use,
Notes/Footnotes: W95, NT (6)
And so on.
The 'headers' attribute works even when table headings are not aligned logically with the data cells they apply to. i.e. when headers and the corresponding data are not part of the same column or row.
For simple tables, where the column or row headers do correspond, the id/headers pair can be replaced with the 'scope' attribute. The scope attribute can have a value of 'col', 'row', colgroup or rowgroup. When using SCOPE with the value of 'col' (i.e scope ="col") - you are saying to the browser (or relevant user agent) ' everything in this column relates to this heading. An example should make this clear:
Using the first two data rows from the previous table, 'scope' is used as follows:<TABLE border="1" summary="Workarounds for CSS bugs with Internet Explorer 5x, (W=Win '95 M=Mac)" cellpadding="10">
More advanced uses of the scope attribute can be found on the World Wide Web Consortiums Website at: http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4
The techniques above are great for those using non graphical browsers - but they throw up a problem of their own. If the headings in the table are very long it can become a bit tiring to keep having the text read out over and over again for each cell. The answer is to provide an abbreviation to substitute for the long heading. The 'abbr' attribute does this and is used in the following way:
<TH id="header 1" abbr="Property">CSS Property/ Problem</TH>
The first instance of the heading will be read out in full, but subsequent instances will be substituted by the abbreviation, in this case the word 'Property'. This saves time and some more’ brain cycles’ in the process.
With the introduction of HTML 4 and HTML 4.01 the W3C group 'sought remedies for a number of authoring habits that cause problems for users'. One way they did this was to encourage authors to make a clearer separation between document structure and presentation. New elements were added that would further clarify the structure of Web documents.
New elements added include, the AXIS attribute, COL, COLGROUP, THEAD, TBODY, and TFOOT divisions. COL and COLGROUP are poorly implemented in current browsers so I don't advocate their immediate use. Further information about new elements and their use can be found at: http://www.w3c.org
THEAD, TBODY, and TFOOT - in line with the goals of HTML - add further structure to HTML Tables by given information about what parts of the Web page constitute the headers and footers. Browsers can display those headers and footers continuously - while the body of the table scrolls. This is very useful for devices that have small screens such as Palm Pilots or Web connected telephones. These are not yet supported by all common browsers.
The THEAD and TFOOT contain the table row that holds the identifying labels for the table's columns. TBODY contains the actual rows of data. Even though TFOOT will appear at the bottom of the table, the W3C HTML 4 standard specifies that it should be specified immediately after THEAD and before TBODY. This allows a part of the table to be displayed quickly - as the 'user agent' does not need to read the entire table before it can display the first screen.E.g. <TABLE>
Specifying the TFOOT before the TBODY causes problems for browsers that do not support the TFOOT tag such as versions of Netscape, earlier than version 6. When the TFOOT tag is not recognised the footer information will be displayed incorrectly, i.e. at the top of the table just below the table header. If you would like to use the TFOOT tag the best workaround for this is to specify the TFOOT after the TBODY tag - despite the fact that this goes against the current standard.
The AXIS attribute is a more sophisticated version of the 'headers' attribute - and can show relationships between groups of cells anywhere in the table. For those coding tables by hand the AXIS attribute will not - I fear - be heavily used because it is a bit of a brain twister to set up. Only when this new technique finds its way in into WYSWYG Web design applications will we start to see it more often on Web pages. An explanation of the 'axis' attribute with an example can be found on the Web Review site (http://www.webreview.com/2001/04_27/webauthors/index04.shtml).
One final thought worth mentioning for the sake of completeness: You should avoid using the PRE element for tabular layout of data - the correct use of the TABLE element is prefered as it allows assistive technologies to take advantage of the TABLE accessibility features.
New tags introduced by HTML 4 provide valuable structure to data tables and their use helps to increase the accessibility of data table for both people using access technologies and those using the proliferation of new Internet connected technologies - particularly those with small screens, or hands free operation. However, many tags are still poorly implemented on current browsers (e.g COL and COLGROUP) - so a pragmatic approach is required.
To sum up, I am still recommending the use of tables for the layout of pages on the Web, despite the fact that this goes against current standards. This a pragmatic approach - not my preferred option. The hope is that very soon the tools used to build Websites will be based on using CSS, rather than tables for layout, and will incorporate all of the necessary workarounds for known bugs, so that the resulting pages will work perfectly on up-to-date browsers - but still be usable on old non-standards compliant browsers. By the same token browser manufacturers will continue to make their products more standards compliant and less buggy.
In relation to the display of information on a computer screen and their accessibility to 'old-style' screen readers the notion that you should only use tables for data and not for layout is not a black and white issue. Tables containing data (where the data spans more than one line in each cell) are no more accessible than tables used for layout. Screen readers that have no capacity to see the HTML structure of a page merely read left to right across the screen a line at a time. So whether it is reading the data in a table cell or the text from an article makes no difference; unless columns of text make sense when read a line at a time, across the screen, the page will be inaccessible.
Continuing this line of thought - if you use a screen reader that does understand HTML - why not just alter the current 'standard' and introduce two new table attributes, 'data' and 'layout' - and let the screen reader deal with the information accordingly. It might work for those using conventional computers and conventional visual display - but the reason this might not be a good idea is that HTML is not meant to be about presentation (on a computer screen or any other device). The idea is that HTML should markup up the structure of a documents content - giving information about the type and 'meaning' of information each tag contains. It may only be in the future when there are less PCs, as a proportion of all Internet connected devices on the Web, and we see more automatic computer processing of Website content that we will see the real benefits of maintaining a distinction between the structure and presentation of HTML documents. That's when we can look forward to some real 'payback'; when everyone has agreed what the standards are - and is acting accordingly.
The relevant parts of the guidelines say,
Guideline 5. Create tables that transform gracefully.
Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.
Tables should be used to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers (refer to checkpoint 10.3)......
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2] Note. Once user agents support style sheet positioning, tables should not be used for layout. Refer also to checkpoint 3.3.
Note the words 'should not use tables for layout', are qualified by 5.3, 'unless the table makes sense when linearized'. The note attached to guideline 5.3 says 'Once user agents support style sheet positioning, tables should not be used for layout.'
Therefore given that:
User agents do not yet support reliable and 'usable' style sheet positioning, as has been demonstrated in this article, nevertheless it is possible to create layout tables that make sense when linearized. My interpretation of the W3C Guidelines is that tables can be used for layout, certainly until Cascading Style Sheets for layout become more reliable.