Disallow tables to be used for presentational purposes

Summary

ISSUE-130: Disallow authors from writing inaccessible documents by abusing table semantics.

Rationale

The original Issue suggests that, since authors can use ARIA to explicitly mark a table as presentational, there is no longer any reason to forbid using tables for layout. However, there are *many* reasons why using tables for layout is bad that are still relevant and not addressed by the Issue or Change Proposal. Thus, using tables for layout is still a bad practice in general, and should continue to be forbidden.

Source order

It is good practice to order your page source by importance, so that the most useful content is at the top, while nav bars and such are further down. This has been at least somewhat possible for years with good CSS layouts, and will become easier as newer CSS layout modules get supported in the coming years. Sites using tables for layout, though, commonly have bad source ordering, due to the particular structure imposed by tables.

Screen readers, by necessity, have developed heuristics enabling them to muddle through these kinds of pages and still present something half-coherent to the user, but these heuristics are unreliable in the first place (thus we should not encourage markup patterns that would require more usage of them) and undocumented and expensive to produce (thus we should not encourage markup patterns that make it significantly more expensive for new screen readers to be developed).

Summary: We should encourage authoring practices that lead to better accessibility.

Maintainability

A well-written page using CSS to handle its layout can be modified and switched around without great effort. Even mediocre pages using CSS aren't overly difficult to modify. Every webdev who has attempted to modify a table-based layout written by someone else, however, can attest that modifications are extremely difficult, and prone to confusing bugs (especially as malformed tables can trigger exceptionally surprising fix-up behavior).

Summary: We should not encourage markup patterns that greatly damage the ability to maintain web pages.

Device independence

It is relatively easy to make pages written with CSS-based layouts work well on devices with differing screen widths, such as mobile phones, automatically. In general, table-based layouts are much harder to do this on, as they tend to use precise dimensions, and often break in odd ways if things are resized unexpectedly.

CSS also exposes functionality (Media Queries) that allow authors to change the layout of pages based on the screen width, so they can manually tailor the display of the page to specific devices. Table-based layouts cannot take advantage of this functionality, as the layout is specified in the HTML.

Summary: We should not encourage markup patterns that are, in the common case, device-dependent and difficult to modify.

Evangelism

Since HTML4 and before, "don't use table-based layouts" has been one of the loudest and most consistent evangelism points. Contradicting this advice with a nuanced position ("It's okay to use table-based layouts, as long as you add this attribute, and don't use them to create bad source orders, and very carefully ensure that your page works well across different devices, etc...") would be damaging to the specific cause of creating accessible pages (nuance is often lost as the message is communicated, leaving us with just "It's okay to use table-based layouts"), and in general would deal a blow to evangelism ("Why was I listening to you people all these years when all I have to do is slap an attribute on my table to make everything hunky-dory?").

Since evangelism is the primary method by which Web designers learn good accessibility and authoring techniques, harming traditional advocates would harm accessibility for users over the long term, and users are considered more important than authors in our priority of constituencies.

Summary: Replacing still-correct good advice with seemingly-contradictory nuanced advice harms accessibility.

Semantics

It is important to remember that there are more than two kinds of user agents; there are at least three:

1. User agents with scripting, CSS, etc, which can be made to render elements (like TABLE) indistinguishably from layout tools.
2. User agents with ATs, which report the accessibility mapping described with ARIA, dropping the element if role=presentational.
3. User agents without CSS support or without scripting support, and certainly without ATs, which always use the default semantics of the elements.

Some examples of #3 are the text-based browsers, most search engines, and graphical browsers in which CSS or scripting are disabled.

The only way to keep things consistent amongst all three is to use HTML elements appropriately. A document that uses tables for layout will look mighty odd in a browser that renders the document according to its semantics.

Summary: Just using ARIA to set role=presentational does not mean you have made the table indistinguishable from DIVs in all browsers.

Poor solution for layout

Tables are a poor solution for layout anyway, compared to alternative technologies like CSS:

• They take more bandwidth. (Equivalent HTML+CSS files are smaller.)
• They aren't as cacheable. (CSS files get cached across a site so only the content needs to be transferred each time.)
• They require you to cut images into smaller pieces rather than being able to position a single image. (CSS lets you use the images in their original complete form.)
• They require massive structural changes to the page in order to change the layout. (CSS files can be replaced without touching the HTML files.)
• They are not rendered incrementally in many browsers, leading them to render more slowly. (CSS files can apply to incomplete DOMs so they can render incrementally.)

Summary: We would be doing authors a disservice by encouraging them to use tables for layout rather than pushing them towards better alternatives.

The future

Over the past decade or more, Web designers have been moving away from tables for layout. For a while, limitations in the market leading Web browser made this somewhat impractical for sites with complicated flexible layouts that had to be compatible with a broad range of user agents, but this is no longer the case, and new sites can avoid using tables without difficulty. Old sites won't change, but old sites are not affected by changes to conformance criteria, since they already exist. Conformance criteria only affect actively developed sites, and those can move away from tables (and many avoid using tables at all).

Summary: This conformance requirement is consistent with the way modern Web designers author documents and applications.

Details

No changes necessary.

Impact

Positive Effects

• During the natural Web site redesign life cycle, authors can implement HTML5 requirements and features, improving the long-term maintainability and accessibility of their sites.

Negative Effects

• None.

Conformance Classes Changes

None.

Risks

None.

References

• HTML 4.01 Specification, Section 11.1 Introduction to Tables, http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.1