- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 05 Apr 2011 10:19:14 -0400
- To: HTML WG <public-html@w3.org>
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.
Received on Tuesday, 5 April 2011 14:19:50 UTC