W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Change proposal for ISSUE-32

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Jul 2010 18:00:17 +0000 (UTC)
To: public-html@w3.org
Message-ID: <Pine.LNX.4.64.1007151758510.24444@ps20323.dreamhostps.com>


Drop the summary="" attribute.


HTML has a feature that allows multidimensional data to be marked up
and presented in a primarily two-dimensional fashion, namely the
<table> element. This feature also has a few features to express more
complex data, such as <th> vs <td>, headers="", scope="",
<thead>/<tbody>/<tfoot>, and colspan=""/rowspan="".

Users of screen readers are able to navigate straight-forward
two-dimensional tables reasonably easily; screen readers have
developed a set of navigation features that allows users to quickly
skim cells horizontally and vertically and also enables users to
easily determine their current position. A simple table with a series
of data cells with the top row and left column containing headers can
therefore be read relatively simply by screen-reader users, by
skimming the first row to get an idea of the fields in the data,
skimming the first column to get an idea of the various options that
the table covers, and then walking through to the relevant cells to
get whatever information is desired, potentially walking a series of
cells in a row or column to get information relating to the range of
the data.

Users of visual user agents [1] interact with such tables in a
remarkably similar way, first reading the headers in the first row of
the table, then reading the headers of the rows, and then using this
information to pin down the cell or series of cells in which they are
interested. However, it is typically a much more instinctive behaviour
than the more belaboured and interactive experience of a screen-reader

([1] For the purpose of this discussion, I shall consider
screen-reader/ browser combinations as being non-visual user agents,
even though in they are actually strictly speaking visual user agents

In addition, screen readers would be most helpful to their users if
they could programmatically summarise table structures
automatically. Indeed, many do report basic table information such as
the number of rows and columns; going forward, it seems likely that
this can and should be improved to describe basic table types, so that
even simpler tables or tables that might lack necessary descriptive
text can be explained.

However, things get more difficult with complicated tables such as
some of the ones studied by Ben a few years ago:


For these, users -- both users of visual user agents and users of
screen readers -- would benefit greatly from some human-written
explanatory or introductory text. Screen reader users are especially
in need of such text, since they cannot see the patterns that visual
user might see.

Explanatory text could be put in several places:

 - Before the table in the prose:


 - After the table in the prose:


In the two cases above, ARIA attributes could be used to more tightly
couple the two to enable screen readers to provide a link between

 - As part of a <figure> with the table:


 - As part of a caption:


All of the examples above are about equivalent; different authors
might prefer different options in different cases. (The spec
encourages the fourth, with the caption, because it links the
explanatory text to the table in a clear way for screen readers, has
the preferred behaviour in existing screen-readers, and doesn't
require the use of a separate <figure> element, which is not always

US goverment advice on how to include explanatory text suggests using
the <caption> or putting content adjacent to the table, as in the
first four solutions above:

| [...] web developers who are interested in summarizing their tables 
| should consider placing their descriptions either adjacent to their 
| tables or in the body of the table, using such tags as the CAPTION tag.
 -- http://www.access-board.gov/sec508/guide/1194.22.htm#(g)

We are therefore in good company in recommending these techniques.

 - Introducing a new element around <table>, e.g.:

      <summary> ... </summary>

Unfortunately there are parsing issues with this.

 - Introducing a new element inside <caption>, e.g.:


 - Introducing a new element inside <figure>, e.g.:


This would make sense if the summary content was rendered very
differently than other content in specific media, but in practice in
ATs the summary content is just read out like caption content, so it
wouldn't add much here, and in other UAs the author would be able to
just style it using CSS. (Media queries can also be used to hide
content specifically from particular media, e.g. having text not
appear on screen.)

 - Reusing <details>:

        <legend> Help... </legend>

This is again reasonable, and the spec does allow this, so it could be
used if desired.

 - Using the summary="" attribute from HTML4:

     <table summary="...">

This last option, which is currently allowed (though discouraged) in
the HTML5 spec, has a number of drawbacks. It only allows simple,
un-marked-up text; it isn't visible to non-screen-reader users in
legacy user agents; and visual media browsers would not want to show
this content inline in legacy content because it would cause legacy
content to change rendering in a non-backwards-compatible manner.

However, some have argued that the summary="" attribute is a better
solution to the problem described above than the other solutions
suggested above.

Here is some empirical data that suggests otherwise.


   A manual crawl of government pages with a summary="". Let us
   examine these tables. First, it's worth noting that this data
   represents the best of the best that we might expect from Web
   authors -- the authors of these tables were legally bound to make
   them as accessible as possible, so it's unlikely that we will see
   any better results anywhere.


      The summary="" value would be useful to all users, yet users
      that don't see the attribute's value have no way to find out the


      The summary="" value duplicates information in the page header
      and the page title, and could without harming visual users have
      been put in the caption. In addition, again, the summary="" has
      information that is not available anywhere else, leaving non-AT
      users out in the cold.


      This entire table is non-conforming (it's a layout table), so it
      doesn't matter if we allow summary="" for it or not. The table
      shouldn't exist. No summary required. (This summary="" is
      inserted by script, no less.)


      There are a number of tables here, and none of them have useful
      summary="" attributes. A number of them duplicate existing
      captions, leading to a suboptimal experience for users of AT
      products. Several of them have one-word summaries that are more
      vague than the first cell of the table, and therefore do nothing
      to help the user. The remainder are layout tables that would be
      better done using <dl>, and the summary="" attributes would be
      better as captions if they are needed at all.


      These summary="" attributes once again give information that I
      would find useful as a non-AT user. They also duplicate some of
      the information in the headers before the table. Would be better
      as a caption.


      The summary says something that is not about the table that
      isn't provided anywhere else, and it repeats information in the
      caption.  (The summary is "National Childhood Vaccine Injury Act
      Vaccine Injury Table", whereas the page is titled "National
      Vaccine Injury Compensation Program" and the table is captioned
      "Vaccine Injury Table".) I can't tell if this is because the
      summary is out of date, or because the page header is out of
      date, but in either case, _someone_ would be better off if the
      summary hadn't been there, and the AT user would not have been
      worse off.


      The summary is a word-for-word repeat of the first row's table
      header cells, which doesn't seem helpful since the user would
      get the same information either way.


      Both tables are non-conforming. The AT user would be better off
      with neither table nor summary.


      The table with the summary="" is non-conforming; the AT user
      would again be better off without either it or its summary.


      The summary is a useless repetition of the header before it, and
      it is the caption that includes information on how to use the

   The conclusion I draw from this data is that summary="" hurts users
   who don't have access to it, hiding information that they could
   use, hurts users who DO have access to it, encouraging people to
   consider layout tables acceptable; and hurts the authors writing
   these tables, wasting their time writing summaries when their time
   would be better spent making pages accessible to _everyone_.

   It's worth noting again that this data is representative of the
   very best that we can expect from Web authors.


   Usability study. A blind user, using JAWS, upon being introduced to
   a sample table with the summary="" attribute, says, unprompted:
   "Now it gave a little summary information there. And I'm wondering,
   how necessary is that. [...] I'm thinking it's too much. [...] I
   think you'll find that information yourself anyway by just
   exploring the table." He then goes on to say that other people
   might disagree, but adds "but for me, they're annoying". He also
   notes that he believes he has the feature disabled in his
   installation, though this contradicts statements by Steven saying
   that summaries aren't disablable in Jaws:



   Automated crawls through two different corpuses. These show actual
   values of summary="", unfiltered for layout tables. Simon went
   through the last (and biggest) list one at a time, and reported
   finding only one page (out of 425,000) with a summary="" value that
   actually fit the recommended guidelines, and pointed out that for
   that table, the summary was in fact redundant and didn't help


   Of the other values, almost all are outright bogus ("pid991460"),
   but some have values that appear to be well-meaning but of
   questionable practical use, such as "Calendar". In fact, when I
   myself went and looked at this set of pages in more detail, I
   concluded that even summary="" values that look like they have a
   chance at being useful aren't actually useful:


Overall I think the data pretty clearly speaks to the problems that
summary="" have today. After ten years of evangelisation and education
efforts, authors *who intend to help users with accessibility needs*
still do not use the attribute in a useful manner. That these
well-meaning authors so fundamentally don't understand how to make
table explanations useful IMHO is an indication that we need to change
how we are going about the problem. This suggests that it is better to
suggest authors include explanatory text in an immediately visible
manner. This would force them to see the text even if they do only the
most primitive of QA (as apparently many do). If the authors see the
text, then they are more likely to make it sensible. This would then
help the users they want to help, and the users for which we want to
make the Web a better place.

Furthermore, the summary="" attribute is intended only for non-sighted
users, which runs contrary to our design principles of universal
access. Hiding information from sighted users even when the
information would be useful to them is not good design. Consider the
exact opposite case: <canvas> and <img> are intended only for sighted
users. Does that mean that it's ok for the content in those elements
to be hidden from non-sighted users? No! We have to convey the
information from those elements to _all_ users, hence <canvas>
fallback and alt="".

Naturally, supporting legacy content that already uses the summary=""
attribute should not be prevented; to this end, HTML5 in fact
encourages user agents (such as screen readers) to expose the contents
of summary="" attributes, even though the attribute isn't part of the
language. That should not be changed.

In conclusion, there's been no evidence presented that there are
authors who:

 * have tables complicated enough that non-visual users need a
   description, and

 * are able to write a description, and

 * are not willing to expose this description to all users, and

 * are not willing to use CSS techniques or <details> to hide the
   information from the default visual presentation, and

 * will remember to update the attribute when the table changes.

There is, however, ample evidence that authors who are convinced (by
advocacy) that they fall into the above situation in fact fail to fall
into it, and end up creating harmful content (see above for
examples). There is also ample evidence that having the attribute
present encourages authors to include descriptions when they are not
necessary, wasting their time and the time of their AT-using readers.

Therefore, having the attribute causes more harm than not having it,
and we should remove it.

Make the summary="" attribute entirely obsolete.


* Improved overall accessibility of the Web.
* Reduced waste of authoring time.


Authors: The attribute is made entirely obsolete.

There may be cases where there is some tabular data of a nature
complicated enough to warrant a table explanation for screen reader
users (and presumably for other users also), but for which the author
will refuse to include visible explanatory text yet is amenable to
including hidden explanatory text. It seems highly unlikely that such
a case exists, and indeed no examples of such a case have ever been
put forward, but if such a case exists then there could be an argument
for leaving the summary="" attribute.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 July 2010 18:00:47 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:21 UTC