This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The HTML 5 specification states that for table (http://dev.w3.org/html5/spec/tabular-data.html#the-table-element) that it must not be used as a layout aid. This text should be struck from the specification: "Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming, because tools attempting to extract tabular data from such documents would obtain very confusing results. In particular, users of accessibility tools like screen readers are likely to find it very difficult to navigate pages with tables used for layout." Tables are used extensively in most Widget libraries (like Dojo) for layout in order to get fidelity across browsers that authors cannot achieve through the use of CSS. Authors simply mark a table with role="presentation" and the problem of interoperability with screen readers goes away. The JAWS screen reader supports the Dojo widget library including ARIA-enabled grids where portions of the grid implementation use grids for layouts.
(In reply to comment #0) > Tables are used extensively in most Widget libraries (like Dojo) for layout in > order to get fidelity across browsers that authors cannot achieve through the > use of CSS. I'm not opposed to replacing the text "users of accessibility tools like screen readers" with a rubric like "users of older accessibility tools that do not support ARIA", but Can clients that do not support CSS present the users with the same content and functionality? Can users still access all content and functionality when they reject the author's styles in favour of their own preferences? Can users easily reformat content that uses tables for layout with CSS or abstractions on top of CSS, as required by WCAG2 1.3? I'm not convinced, but can you point to some examples that demonstrate these properties? If so, then it might be okay to allow tables to be used as layout aids *only* when annotated with role="presentation".
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This restriction has been in HTML for over a decade (and indeed since long before I was even out of high school). Allowing HTML tables to be used for layout would undo literally over a decade's worth of accessibility advocacy.
(In reply to comment #2) > Allowing HTML tables to be > used for layout would undo literally over a decade's worth of accessibility > advocacy. I thought the reporter's point was that the advocacy is obsoleted by role=presentation.
I am not satisfied with the this being closed, with a won't fix, because it was in HTML 4. You cannot, with complete certainty, test that a table is being used for layout and so much of the web uses tables for layout to ensure fidelity across browsers. The entire Dojo library, gmail, and millions of other applications would be non-compliant per this outdated assertion. We now have a vehicle to state whether tables are used for layouts. Web applications also have the ability to determine the device they are delivering to and can compensate their rendering based on the device. Also, the point in HTML 4 about having to perform horizontal scrolling would be the case if you had a table that was used as an actual table. From an accessibility perspective, the author has the ability to declare that a table is being used for presentation. I see no point in including this directive in HTML anymore as clearly the industry pays little or no attention to this requirement. I would close that longdesc was in HTML 5 too yet people are attempting to remove it from the spec for not being used. Yet here, we have a clear case where tables are used extensively for layout and Ian does not want to remove it. The argument has no logical basis and is inconsistent with how developers create web applications today.
added TrackerRequest on behalf of Rich Schwerdtfeger
Don't add TrackerRequest for a reopened bug.
Raised as Issue-130
TrackerIssue
http://lists.w3.org/Archives/Public/public-html/2010Dec/0119.html
http://lists.w3.org/Archives/Public/public-html/2010Dec/0132.html
The bug-triage sub-team thinks this is TF priority. We need to make sure the accessibility community provides consistent advice on layout tables and provides solid and consistent rationales. Otherwise people working on different aspects of the issue end up talking past each other and royally confusing people outside the accessibility community. Therefore, the TF should develop a consensus position and rationale. Also, adding reference to http://www.w3.org/html/wg/tracker/issues/130, the tracker issue to which this was escalated. TF discussion should take place in context of that issue.
Change proposal is here: http://www.w3.org/html/wg/wiki/ChangeProposals/layouttables
Personally, I am for making the fact that tables should not be used for layout informative.
Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Mar/0245.html
Checked in as WHATWG revision r6006. Check-in comment: apply wg decision http://html5.org/tools/web-apps-tracker?from=6005&to=6006
*** Bug 12323 has been marked as a duplicate of this bug. ***
""should not" implies that there may be valid reasons to use tables for layout, which there are not." You forgot about HTML email.