- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 21 Jul 2010 15:26:57 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-html@w3.org
I have recorded this Change Proposal on the issue status list:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-032
If anyone else wants to submit any further proposals, the final deadline is on July 23.
Regards,
Maciej
On Jul 15, 2010, at 11:00 AM, Ian Hickson wrote:
>
> ISSUE-32
> ========
>
> SUMMARY
> Drop the summary="" attribute.
>
> RATIONALE
>
> 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
> user.
>
> ([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
> also.)
>
> 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:
>
> http://projectcerbera.com/web/study/2007/tables
> http://projectcerbera.com/web/study/2008/tables
>
> 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:
>
> <p>...</p>
> <table>...</table>
>
> - After the table in the prose:
>
> <table>...</table>
> <p>...</p>
>
> 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
> them.
>
> - As part of a <figure> with the table:
>
> <figure>
> <p>...</p>
> <table>...</table>
> </figure>
>
> - As part of a caption:
>
> <table>
> <caption>
> ...
> <p>...</p>
> </caption>
> ...
> </table>
>
> 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
> desireable.)
>
> 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.:
>
> <table>
> <summary> ... </summary>
> ...
> </table>
>
> Unfortunately there are parsing issues with this.
>
> - Introducing a new element inside <caption>, e.g.:
>
> <table>
> <caption>
> ...
> <summary>...</summary>
> </caption>
> ...
> </table>
>
> - Introducing a new element inside <figure>, e.g.:
>
> <figure>
> <summary>...</summary>
> <table>...</table>
> </figure>
>
> 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>:
>
> <table>
> <caption>
> ...
> <details>
> <legend> Help... </legend>
> ...
> </details>
> </caption>
> ...
> </table>
>
> 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="...">
> ...
> </table>
>
> 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.
>
> http://www.paciellogroup.com/blog/misc/summary.html
>
> 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.
>
> http://www.fbi.gov/ucr/cius2007/data/table_01.html
>
> 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
> information.
>
> http://www.cdc.gov/asthma/nhis/04/table1-1.htm
>
> 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.
>
> http://www.eia.doe.gov/cneaf/electricity/epm/table1_13_a.html
>
> 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.)
>
> http://www.vrg.org/journal/vj2006issue2/vj2006issue2mealplans.htm
>
> 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.
>
> http://www.irs.gov/formspubs/article/0,,id=164272,00.html
>
> 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.
>
> http://www.hrsa.gov/vaccinecompensation/table.htm
>
> 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.
>
> http://www.cslib.org/finespenalt.htm
>
> 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.
>
> http://aspe.hhs.gov/poverty/faq.shtml
>
> Both tables are non-conforming. The AT user would be better off
> with neither table nor summary.
>
> http://www.ssa.gov/OACT/STATS/table4c6.html
>
> The table with the summary="" is non-conforming; the AT user
> would again be better off without either it or its summary.
>
> http://www.nhlbi.nih.gov/guidelines/obesity/bmi_tbl.htm
>
> The summary is a useless repetition of the header before it, and
> it is the caption that includes information on how to use the
> table!
>
> 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.
>
>
> http://www.youtube.com/watch?v=xMGBX8gAM6g#t=0m30s
>
> 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:
>
> http://lists.w3.org/Archives/Public/public-html/2009Jun/0282.html
>
>
> http://canvex.lazyilluminati.com/misc/summary.html
> http://canvex.lazyilluminati.com/misc/summary-20090226.html
> http://philip.html5.org/data/table-summary-values-dotbot.html
>
> 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
> accessibility:
>
> http://lists.w3.org/Archives/Public/public-html/2009Jun/0698.html
>
> 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:
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0104.html
>
>
> 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.
>
>
> DETAILS
> Make the summary="" attribute entirely obsolete.
>
> IMPACT
>
> POSITIVE EFFECTS
> * Improved overall accessibility of the Web.
> * Reduced waste of authoring time.
>
> NEGATIVE EFFECTS
> None.
>
> CONFORMANCE CLASS CHANGES
> Authors: The attribute is made entirely obsolete.
>
> RISKS
> 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 Wednesday, 21 July 2010 22:27:31 UTC