Forwarded message 1
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 there should
be provisions made for a separate summary for tables, a disagreement as
to what that such a summary should be used for, and a disagreement as
to whether such a summary should be expressed as an element or an
attribute. The result was an issue, four change proposals, and a straw
poll for objections:
http://www.w3.org/html/wg/tracker/issues/32
http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18%2C_2009
http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222
http://lists.w3.org/Archives/Public/public-html/2010Jul/0052.html
http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element
http://www.w3.org/2002/09/wbs/40318/issue-32-objection-poll/results
We also received a consensus recommendation of the HTML A11Y Task Force
(with objections):
http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0088.html
=== Objections on the basis of "hidden metadata" and other risks
With four change proposals, there wasn't much that was uncontested.
The change proposal for "Change Proposal for Table Summary and related
accessibility features" offered the following:
* Summary is still "hidden metadata." Because authors and testers
don't encounter it in their daily activities, hidden metadata has
the risk of being incorrect or getting out of date; concern that
any human-readable content which is not visible to authors in
mainstream browsers with default settings will frequently not be
added or kept up to date by authors
* Risk that AT vendors will not improve the user experience; risk
that DOM and accessibility APIs, will not be adopted
The first observation was contested by some (and the term "discoverable
meta-data" proposed in its place). Others suggested that "Browser
vendors are free to provide the information of the summary attribute in
a way that benefits other users than those with AT".
Either way, neither of these observations were decisive. There were
people who supported each of the four proposals even after taking these
facts into consideration. The fact that they were acknowledged up
front was appreciated.
Finally, the 'Drop the summary="" attribute' Change Proposal offered a
risk that will be covered later in the decision.
=== Objections on Syntax
Two of the change proposals proposed an attribute, one proposed an
element, and one proposed dropping it entirely. To reduce the number
of proposals under consideration, we started by looking at objections
based on syntax considerations alone. First objections on expressing
summary via an attribute, taken from the survey:
I object to this useful information being hidden in an attribute. It
should be in the content (for example, within the caption) and
rendered (spoken and visible) by default.
I object to the information presented in summary to be hidden by
default in the attribute's value as some sighted users might benefit
from it as well.
Summary as an attribute is insufficient because it does not support
structured content, such as <span lang="xx"> for bi-lingual tables,
as well as indicating to the user that the table uses structured
markup and a guide to that structured markup.
Looking at objections to providing summary as an element, we don't find
any which specifically apply to the proposed syntax. What we do have
is the following from the survey:
In the absense of a better replacement, we need to keep the
accessiblity features from HTML 4. We do not currently have a better
replacement for @summary, and creating one is not the highest
priority work item on the very aggressive schedule for HTML 5.
This comment was entered into the survey prior to the addition of a
fourth proposal that does propose to replace the summary attribute with
something asserted to be 'better'.
Next, we have an objection to both syntaxes based on the argument that
either would be "encouraging a redundant feature". The assertion is
that aria-describedby "solves the same use cases, but does it in a
better way." Specifically, there already exists mechanisms to make
this description available to non-AT users should that be desirable, or
to make it available only to AT users via the addition of
style="display:none" attribute to the element containing the summary.
Additionally, this attribute is available not only on tables, but is
made available consistently across all elements. Finally, we have
assertions of growing momentum behind aria-describedby.
Again, these comments were entered into the survey prior to the survey
being reopened. No counter arguments were made against this objection,
even after the survey was reopened months later.
Finally, there were objections based on compatibility. We found
mention of "Obsolescing summary breaks the web for numerous sites doing
the right thing" and "HTML5 should not ignore existing laws and
requirements", but in each case such statements were paired with, and
generally appeared after statements of "NO CURRENT REPLACEMENT". There
was a mention of "Do not Reinvent the Wheel", but even there it was
noted that this principle is without consensus, and this principle was
also cited in the "Why Summary Should Not Be Provided" section. There
is even a mention of obsolescing/deprecating the summary attribute in
favor of aria-describedby.
Based on this, we concluded that the arguments for compatibility were
weak.
Additionally, there were the following specific objections to the
"Change summary from an Attribute to an Element" Change Proposal: that
it does not precisely define the term "activatable text", nor does it
adequately define the content model of this proposed element in terms
of what children may be directly included and what children those
element may contain.
We therefore find that expressing this concept as a separate element
drew weaker objections than expressing this concept as an attribute.
We also find that the proposal to use one of several existing elements,
and possibly link that element via the existing aria-describedby
attribute, drew weaker objections than the proposal to change summary
from an attribute to an element."
=== Objections on the basis of Need
The primary distinction between the 'Drop the summary="" attribute'
proposal and all the remaining proposals is a disagreement as to
whether or not a summary is necessary or useful at all. First a quote
from the "Change Proposal for Table Summary and related accessibility
features":
an author could suggest other overview information that might be
immediately obvious to someone looking at the table but would take
time to draw the same conclusions when accessing the table aurally.
This would include highlighting trends, the largest or smallest
values, etc., and describing the purpose of the table. It could also
summarize the purpose of the table, that is, what the author wants
the reader to draw from the inclusion of the table.
The following are taken from the survey:
I object to the use of "obvious from viewing the table visually"—we
all face different challenges when understanding information, whether
it be text, graphical, aural or tabular. We should make features like
"summary" universally accessible. Many people who can "see" the table
may have difficulty comprehending the trends and would be assisted by
the summary.
Tables essentially fall into two categories:... If the structure is
complex or non-obvious enough to prevent a machine from
auto-generating a sufficient summary, then it is almost certainly
complex or non-obvious enough that sighted users may be confused by
the table layout as well... Thus, in neither case do you need a
summary available only to ATs or non-sighted users
summary="" has been amply demonstrated (one might even say _proved_)
to not help improve accessibility in concrete ways. As such, it is
just acting as an opportunity cost, encouraging authors from spending
time on something other than improving accessibility *even after we
are lucky enough to have found an author who cares about
accessibility*. This is a net harm to the accessibility of the Web.
Also found in the survey is a response to the claim made in the final
paragraph above. This response is included here verbatim:
No it hasn't.
Key words from each of the above paragraphs: "could", "should", "may",
"almost certainly", and "amply demonstrated". Each provides hints as
to the relative strengths of the objections which contains these
paragraphs.
Looking at 'Drop the summary="" attribute' we do find "demonstration"
in the form of empirical data and a Usability study. Whether or not
this demonstration is "ample" is in dispute.
Additionally, we find the following in the "RISKS" section of the very
same Change Proposal:
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.
Looking at the "Make the summary attribute fully conforming and allow
visual UAs to optionally expose it" Change Proposal, we do see a list
of use cases. We also have a list of sites that make use of a summary
(in the form of the current attribute for this purpose). These use
cases are not specifically addressed by any objection or counter
proposal.
All we have is the assertion that the need for a separate summary is
"almost certainly" not needed, that it is "highly unlikely" that such a
case exists, and an identification of a small number of sites where
summary was used improperly. As these assertions are made without
addressing the use cases that are presented, these assertions were not
found to be credible.
We do have a larger study from a few years ago that indicates that the
summary attribute is often misused. No claim was made as to whether
such a finding would apply to a separate summary element or the usage
of an aria-describedby attribute.
Overall, we continue to find that proposals that involve expressing
summary in attribute form to attract stronger objections than the
alternatives. Between the remaining two proposals, we find the
objections to introducing a new summary element to be stronger than
simply relying on the existing aria-describedby attribute.
For completeness, we look at the objections to the remaining proposal
to see if there is a stronger objection than any of the ones that we
have evaluated so far.
=== Objections to 'Drop the summary="" attribute'
We start with the positive effects listed in the other three change
proposals:
Authors would have a mechanism for providing to non-visual users the
information that is difficult for them to glean by navigating around
the table.
This statement applies to each of the mechanisms that we have
evaluated.
Authors who are trying to optimize for accessibility will not get
validator warnings for doing so.
This presumes that the summary attribute is the most appropriate way to
express this information.
Table structure and directionality are separated from summary, and
left to browsers and AT to manage for users. This should mean that
fewer tables require summary.
This is a positive effect relative to an entirely different Change
Proposal. Any motion towards fewer tables requiring a summary is not
an objection to dropping the summary attribute.
HTML and WCAG will not be giving contradictory advice.
A potentially valid objection, but all that statement implies is that
one will need to be updated, without providing any indication as to
which one.
Provides users of screen readers an equal opportunity to hear concise
table summary information for a complex table that is visually
apparent to sighted users.
This presumes that the summary attribute is the most appropriate way to
express this information.
Provides authors a mechanism for providing non-visual users summary
information in a non-visual way.
This presumes that the summary attribute is the most appropriate way to
express this information.
Removes the validator warning penalty for authors who are trying to
optimize for accessibility.
Assumes that the summary attribute is the most appropriate means for
optimizing for accessibility.
Provides authors the ability to expose the summary attribute via a
preference or switch in browser for testing purposes.
Uncontested, but doesn't help make the case that the summary attribute
is the most effective or useful way to express this information.
Provides others who want the ability to expose the summary attribute
content a way to do so.
Uncontested, but doesn't help make the case that the summary attribute
is the most effective or useful way to express this information.
Provides backwards compatibility for users of existing authoring
tools like Dreamweaver.
A valid objection, but given the consistent expression of the sentiment
that summary can and should be replaced with something better, this
objection was not found to be strong.
Provides consideration for Government Laws and WCAG Guidelines.
A potentially valid objection, but all that statement implies is that
one or more will need to be updated, without providing any indication
as to which one(s).
Provides authors with a means of semantically marking summarization
information
This presumes that the summary attribute is the most appropriate way to
express this information.
Now looking at the objections from the survey:
summary is an essential tool for non-visual and limited visual access
to data contained in TABLE
This presumes that the summary attribute is the most appropriate way to
express this information.
In the absense of a better replacement, we need to keep the
accessiblity features from HTML 4. We do not currently have a better
replacement for @summary, and creating one is not the highest
priority work item on the very aggressive schedule for HTML 5.
This fails to address why aria-describedby in an unacceptable
replacement.
What does "part of the language" mean?
This is an objection to a part of a rationale that was not used to
determine the strongest objection.
the test person complains that he summary info is unneeded. There
could be more than one reason why so
A potentially valid objection to the usability study, but as that
evidence wasn't decisive, this objection does not change the overall
decision.
Even if @summar becomes fully valid, it is possible to have very
strict rules for it use, including strict validation rules
This is an objection to a part of a rationale that was not used to
determine the strongest objection.
Although this part of the CP spoke against the possible use of a
<summary> element, the point should also be valid for @summary: the
@summary attribute allows exactly this. Namely it allows the AT to
render it very different from the caption.
We still do not find a single example cited where a summary is used
correctly, nor even a single example cited where adding a summary in
any form (element or attribute) would be helpful.
It is also possible to "just style" the @summary attribute.
Uncontested, but doesn't help make the case that the summary attribute
is the most effective or useful way to express this information.
The legacy argument is difficult. Many things are possible to achieve
via scripting and css if one is willing to.
The legacy argument may not be the strongest objection, but it is still
valid. Either way, this doesn't change the decision.
Stricter validation could help. See above. "Harmful content" is an
exaggeration anyway.
The first sentence is provided without any evidence. The term
"harmful" is clearly subjective. Whether or not this term is an
exaggeration did not affect the outcome of this decision.
As told, there is legacy content with @summary out there. By defining
@summary as not part of the languagge, the legacy content out there
will be forgotten or perhaps removed - without anyting new coming
instead.
While this objection is valid, overall we found that the objections to
replacing summary with something better to be weaker than the
objections to the existing summary attribute.
NO CURRENT REPLACEMENT
This fails to address why aria-describedby in an unacceptable
replacement.
CONSIDERATION FOR AUTHORS
This presumes that the summary attribute is the most appropriate way to
express this information.
Obsolescing summary breaks the web for numerous sites doing the right
thing.
This presumes that the summary attribute is the most appropriate way to
express this information.
HTML5 should not ignore existing laws and requirements.
A potentially valid objection, but all that statement implies is that
one or more will need to be updated, without providing any indication
as to which one(s).
Finally, we explore objections to aria-describedby as a suitable
replacement for the summary attribute. What we find are:
Does not meet the programmatically-determined standard of WCAG.
No explanation is provided as to why a summary element with nested
elements meets the standard of programmatically-determined and another
element with another name with the same content could not.
aria-describedby could be used to provide a long description for the
table, but that's not the purpose of the summary attribute.
From this we infer that aria-describedby is more general purpose.
Lacking use cases that clearly require the more specialized purpose
described here, or an explanation of the operational problems that
adopting a more general purpose element would cause, we find this
objection not to be strong.
ARIA is not an alternative, as e.g. an element pointed to via
ARIA-describedby would not be read in a different tone etc.
We do not find this to be a strong objection as no supporting evidence
was provided that aria-describedby has this limitation, either in
practice or in principle; nor is it explained why such a limitation is
problematic.
*** Decision of the Working Group ***
Therefore, the HTML Working Group hereby adopts the 'drop the
summary="" attribute' Change Proposal for ISSUE-32. Of the Change
Proposals before us, this one has drawn the weaker objections.
== Next Steps ==
Bugs 7539 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-32 is to be
marked as 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.
=== Arguments not considered:
The following objections were not considered:
"this change proposal describes itself quite accurately as a Solomonic
solution. It seems obvious on its face that we should only be
considering technically sound solutions, not solutions that
self-describe themselves as a pretence of a solution."
We are looking for technically sound objections to the proposal, not
objections to how the proposal is described.
Parsing issues with summary as a direct child of table.
This is an objection to something that nobody proposed.
=== Revisiting this Issue
This issue can be reopened if new information come up. Examples of
possible relevant new information include:
* Identification of specific use cases, along with a number of
specific examples from real-world sites, where a separate table
summary would be useful either instead of or in addition to a caption
element or an aria-describedby attribute. Ideally such use cases
would explain why this is needed only for tables but not also for
images or canvas elements which could express the same information
using a different mechanism.
* First hand statements from authors of development tools currently
implementing the summary attribute that the making the summary
attribute obsolete would present an unacceptable burden or that it
would significantly inhibit the adoption of HTML5 by the tools that
they produce.
* Identification of specific operational problems with the
aria-describedby attribute that make it not able to be
programmatically determined or suitable for use as a table summary.