Working Group Decision on ISSUE-130: table-layout

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.

*** Question before the Working Group ***

There is a basic disagreement in the group as to whether table elements
which specify role="presentation" are to be considered conforming.  The
result was an issue, two change proposals, and a straw poll for
objections:

http://www.w3.org/html/wg/tracker/issues/130
http://www.w3.org/html/wg/wiki/ChangeProposals/layouttables
http://www.w3.org/html/wg/wiki/ChangeProposals/NoLayoutTable
http://www.w3.org/2002/09/wbs/40318/issue-130-objection-poll/results

== Uncontested observations:

  * Tables are used for presentation extensively throughout the web.

  * HTML 4 states that tables should not be used for layout

  * We should encourage device independency

  * the feedback from the web authoring community over the years has been
    that they want to move away from (ab)using HTML as presentational
    language.

  * WAI WCAG discourages the use of a table element for anything that's
    not a real data

  * Compared to CSS, tables take more bandwidth, they aren't as
    cacheable, they require you to cut images, they result in pages that
    aren't as maintainable, and aren't rendered incrementally in many
    browsers.

  * The WAI has developed an ARIA role that is now supported in IE,
    Firefox (Windows and Linux), and Safari called "presentation". It is
    also used extensively on the web in libraries like Dojo, hundreds of
    Web 2.0 applications and key assistive technologies like the JAWS
    screen reader. When applied to a table it provides a declarative way
    of stating that the table is being used for layout.

None of these were decisive.  There were people who supported either of
these proposals even after taking these facts into consideration.  The
fact that they were acknowledged up front was appreciated.

We further note that there were plenty of variations of the sentiment
that tables should be discouraged.

=== Objections

We start with what was found to be the strongest objection, which was
the combination of the following two statements:

    a winning accessibility strategy is one that does not put an
    incredible burden on the author. Expecting authors to rewrite their
    web applications to support such a pervasive coding change as to use
    CSS table layouts only infuriates the development community resulting
    in tremendous pushback on accessibility in organizations.  It is much
    less invasive to add an attribute to convey the intent of the author.
    This approach is much easier to implement by authors who have made
    sizeable investments in the use of tables. It is a much lighter
    weight change than having to convert numerous applications, like
    databases to use a CSS Table approach when generating web content.

    The only way to accurately detect a conformance violation is if the
    author set role="presentation" on the table thus penalizing authors
    for producing accessible content.

Taken together, making the use of role="presentation" on table elements
would have the effect of discouraging people from making their content
accessible; and we find that there are strong objections for this to be
done by HTML5.

Following are the remaining objections that we were able to extract.
Each of these are direct quotes followed by an analysis of the strength
of the objection.

    some scenarios presentational tables are perfectly legitimate.

The strength of this objection was weakened considerably by the fact
that no specific scenarios were enumerated.  We note that another
response to the survey indicated that "tables provide a
consistent layout across browsers.".  Taken together, this strengthens
the objection that was already found to be the strongest.

    Since HTML4 and before, "don't use table-based layouts" has been one
    of the loudest and most consistent evangelism points.

This argument cuts both ways.  In response to the survey, we see "the
industry has clearly ignored for over a decade despite the statements in
the HTML 4 specification."  We note that we've seen this argument
before.  In a previous survey it was observed that "no stated reason
that this ... will actually be used more in the coming 10 years than it
has in the past 10 years" to argue that a given feature should NOT be
adopted/retained.  Any argument that can be used both ways is
necessarily a weak argument.

    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).

This assertion does not mention a specific example.   By contrast the
authors of the proposal to make <table role="presention"> conforming
cite gmail, facebook, yahoo mail, numerous IBM applications, and
toolkits such as DOJO and YUI.  As each of these are actively
maintained, we find that there was insufficient evidence provided to
back up this assertion.

    I strongly object to this proposal. HTML is not a presentational
    language. If we want to turn it into a presentational language, or
    some kind of hybrid, we should apply that universally and not just
    punch a hole for tables.

Another response to the survey states "Currently, I don't see a
compelling story behind what the spec forbids and what it allows
(witness other exceptions, such as what kind of values are allowed on
iframe/@width)."  Therefore, at the present time we do not find there to
be consensus within the Working Group as to whether or not HTML contains
markup for presentation purposes.  Nor is it our intent for this
decision to cover anything other than the scope of the original issue.
Note that we have included any potential future finding of consensus on
when presentational aspects are to be allowed as potential "New
Information" sufficient to cause this issue to be reopened.

    ... and actually removes the confusing table semantics from the
    platform accessibility API producing a reliable accessible solution
    and improving assistive technology processing performance."

It is not clear what is being removed (i.e., it is doubtful that all of
the unannotated use of tables for presentational purposes will be
corrected), and there is no data provided on reliability and
performance.  As such, this is a weak objection.

       From an accessibility standpoint, there are a couple of issues:
       screenreaders switch into a table browsing mode, thus navigation
       between data cells is different and much more complex than just
       reading a text. So table layout adds a burden to a screenreader
       user. Also the content of pages with table layout tends to be
       confusing when read in source order, even when the visual
       representation is clear to a sighted user. role="presentation"
       doesn't change this.

This was countered two separate times:

       Although in RNIB we agree that using tables for layout is not
       always good practice (CSS is in most cases a more appropriate
       choice), we also think that the assumption that screen readers
       can't cope with layout tables is as flawed as the assumption
       that all screen readers can cope with the less rigid structure
       of CSS presentation.

       There are developers/authors who would persist in believing that
       layout tables are bad for screen readers. They aren't. Bad ones
       are, as is the inappropriate use of CSS layout.

In all, we find that the case was not made that role="presentation"
"doesn't change this".

       It is important to remember that there are more than two kinds of
       user agents; there are at least three...  User agents without CSS
       support or without scripting support, and certainly without ATs,
       which always use the default semantics of the elements.

This is potentially a valid objection, but fails to explore what happens
in the case where such a user agent does not support ARIA, nor the case
where such a user agent does support ARIA.  In the former case, it does
no harm.  In the latter case, the result would entirely depend on how
ARIA was supported.  In the course of this discussion, a large number of
specific examples were provided where existing sites utilized markup in
a way that could benefit from the "change some role mappings" proposal,
and absolutely none were identified which would harm the user agents
which do not support CSS or scripting but does support ARIA in some
fashion.  As such this objection was considered to be weaker than than
the objections to the alternative.

=== Arguments not considered:

Each of these are direct quotes followed by a reason why the objection
was not considered:

     I object, we don't need this. It is unnecessary, tables are for
     tabular data. </story>

This objection fails to make any sort of case.  Additionally, neither
Change Proposal suggested any change in User Agent behavior for
role="presentation".

     practically, i can live with this change proposal, PROVIDED that:

We only evaluate change proposals which actually were submitted.

     This recommendation should be present in some sort of best practice
     document for HTML authoring or in accessibility guidelines, not
     directly in HTML5 spec.

We only evaluate change proposals which actually were submitted.

     using reverse-engineered heuristics to establish the semantic nature
     of something is flawed. Declaratively marking a table with
     role="presentation" is about as clear as it gets.

No change proposal suggested either removing this attribute or changing
the heuristics.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "Allow tables to be
used for presentational purposes" Proposal for ISSUE-130.  Of the Change
Proposals before us, this one has drawn the weaker objections.

== Next Steps ==

Bug 10963 is to be REOPENED and marked as WGDecision.

Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal.  Once those changes are complete ISSUE-130 is to be
marked closed.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.

== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* evidence that correct usage is growing rapidly and that that growth is
   expected to continue.  Ideally, this usage would include a large of
   the sites that were cited, namely gmail, facebook, yahoo mail, IBM
   applications, and toolkits such as DOJO and YUI.  Alternatively, this
   evidence could include some rationale as to why the cases which are
   cited should outweigh the evidence provided by these cases.

* a substantial list of User Agents which are scripting unaware and CSS
   unaware but are partially ARIA aware to the point where the addition
   of role attributes produces substantially worse results than not
   having such information available provides.  This list would need to
   be accompanied by a specific list of sites that employ such
   problematic markup.  Ideally such evidence would be provided in terms
   of first hand statements by implementers of these tools themselves.

* A comprehensive document over which we have found there to be W3C
   Consensus within the Working Group which defines the strategy by which
   HTML5 approaches making choices for dealing with presentational
   aspects of the language, as well as a comprehensive mapping of this
   strategy to the markup language that HTML5 defines.

Received on Thursday, 10 March 2011 17:36:44 UTC