- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 22 Aug 2011 06:34:08 -0500
- To: Janina Sajka <janina@rednote.net>, Joshue O Connor <joshue.oconnor@cfit.ie>, Léonie Watson <lwatson@nomensa.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, Vlad Alexander <vlad.alexander@xstandard.com>
Hello Janina, Josh, Léonie and all, On 8/19/11, Janina Sajka <janina@rednote.net> wrote: > Please consider the Change Proposal with request to reconsider the > HTML-WG decision on Table Summary Thank you, Josh and Léonie, for working on this change proposal. Lots of good information in: http://www.w3.org/WAI/PF/HTML/wiki/Category:Table_Summary The following are a few ideas to consider. Some are simple suggestions for verbiage replacements and such. Some would require reworking the document's structure to the supply specific grounds for reopening the issue thereby improving the chances of that indeed happening. Basically it would add sub-sections to the Rationale section and rearrange things to something like: 1.1 Summary 1.2 Rationale 1.2.1 Identification of Use Cases 1.2.1.1 Real World Examples in the Wild 1.2.2 aria-describedby 1.2.3 Authors of Development Tools 1.2.4 Current Examples are Problematic 1.2.4.1 Screen Reader Tests 1.3 Details 1.4 Impact 1.4.1 Positive Effects 1.4.2 Negative Effects 1.5 Extending @summary? 1.6 Rebuttals/ Responses to Arguments Against Retaining @summary 1.6.1 Hidden Meta Data 1.6.2 Objections on Syntax 1.6.3 Objections on the basis of Need 1.6.4 Objections to 'Drop the summary="" attribute' 1.7 References Anyway, the following (A-J) are suggestions to consider. A). ADD A DEDICATED "IDENTIFICATION OF USE CASES" SUB-SECTION TO THE RATIONALE SECTION. WHY: To directly and specifically address the Chairs' statement in the decision for new information to reopen the issue. They said the issue could be reopened with: "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." http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html The proposal currently identifies problems with the accessibility of the examples in the spec. I suspect this alone will not be considered sufficient grounds for reopening the issue. As with the longdesc attribute the Chairs do not understand *WHY* @summary is needed. Without this information front and center it is unlikely that the issue will be reopened. Providing formal use cases and basing them on real world examples in the wild would provide that information. * The real world examples provide evidence of use. * The use scenarios provides the story and motivation and the why. Some use case verbiage is interspersed in this proposal. Relocating it into a new dedicated "Identification of Use Cases" section would make it unmistakable that it is in fact new information and rationale to reopen the issue. In other words for this sub-section, cite the Chairs' statement and supply the requested information as prominent rationale. B). ADD A DEDICATED "aria-describedby" SUB-SECTION TO THE RATIONALE SECTION. WHY: To directly and specifically address the Chairs' statement in the decision for new information to reopen the issue. They said the issue could be reopened with: "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." http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html The "Decision History" section of the HTML Working Group's home page provides further insight into the Chairs view on aria-describedby for issue 32: QUOTE 2011-04-05: Drop the summary="" attribute (in favor of the aria-describedby attribute) UNQUOTE http://www.w3.org/html/wg/#events This underscores the need to supply rationale in this new proposal as to why aria-describedby does not negate the need for table summary and why @summary should not be dropped in favor of the aria-describedby attribute. Some aria-describedby verbiage is interspersed in the "Negative Effects" section of the Josh and Léonie's CP . Relocating it into a new dedicated aria-describedby sub-section would make it evident that it is in fact new information for the issue to be reopened. Without new information on aria-describedby it seems doubtful that issue 32 will be reopened. After the initial Issue 32 poll Gez mentioned good rationale that could vey well be added to this sub-section. He said that using ARIA, as a workaround for a table summary would be way too cumbersome for authors. No one would want the text on the screen, as it would state what is visually evident. So to use ARIA, a person would have to write the content, hide it with CSS, an then reference the hidden text with aria-labelledby. That's so cumbersome that surely even the most enthusiastic ARIA supporter should realize that the summary attribute is far more efficient and already well supported. This would be the perfect section to cite and discuss Leif's test page. http://malform.no/testing/html5/table+aria.html Vlad Alexander provides new information that can be quoted directly. http://rebuildingtheweb.com/en/aria-for-content-doomed/ C). ADD A DEDICATED "AUTHORS OF DEVELOPMENT TOOLS" SUB-SECTION TO THE RATIONALE SECTION. WHY: To directly and specifically address the Chairs' statement in the decision for new information needed to reopen the issue. They said the issue could be reopened with: "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." http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html Without new information the issue will NOT be reopened. In other words, cite the Chairs statement and supply the requested information prominently. Vlad Alexander does indeed provide new information that can be quoted directly for this section as well as the ARIA section. http://rebuildingtheweb.com/en/aria-for-content-doomed/ D). RENAME THE "RATIONAL" SECTION "RATIONALE" WHY: There is no "Rational" section in the Change Proposal template. It is a "Rationale" section. "Rationale" is a noun that means the reasoning or principle that underlies or explains a particular course of action, or a statement setting out these reasons or principles. "Rational" is an adjective. E). ADD DETAILS TO THE "DETAILS" SECTION. WHY: The details section lacks any details. This section is a required in a change proposal. It can take one of the following four forms: " *A set of edit instructions, specific enough that they can be applied without ambiguity. *Spec text for a draft to be published separate from HTML5 (though such a draft can be proposed at any time without a Change Proposal). *Exact spec text for the sections to be changed, and a baseline revision for the version of the spec being changed. *With prior permission from the Chairs, a high-level prose description of the changes to be made." http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#change-proposal For ideas check the two previous proposals to reinstate @summary: http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18%2C_2009#Details http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222#Details F). ADD AN "IMPACT" SECTION. WHY: It is missing. An "Impact" section is a required section in a Change Proposal. http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#change-proposal G). MOVE REBUTTALS TO A DEDICATED "REBUTTALS" SECTION: WHY: The verbiage starting with "The following are my responses to the 'Working Group Decision on ISSUE-32 table-summary'" is currently under the "Negative Effects" heading. It is misplaced. The negative effects section is supposed to state real negative effects of a change proposal. In this case it would be any negative effects of reinstating @summary. Currently the verbiage in this section consists of rebuttals to previous unsubstantiated or misguided accusations against @summary. Using the "Negative Effects" for rebuttals legitimizes those accusations as being negative effects of reinstating @summary. So consider putting the current information in a "Responses to Arguments Against Retaining @summary" or simply "REBUTTALS" section. For the "Negative Effects" section state negative effects of reinstating @summary. If it does not have any state: none. Or remove the "Negative Effects" section. It is not a required part of a change proposal. The Impact section is. H). REPLACE THE FOLLOWING VERBIAGE "None of these reasons are definitive, and @summary's current status as obsolete but conforming" WITH: "None of these reasons are definitive, and @summary's current status as obsolete" WHY: The verbiage is incorrect. The table summary attribute now is *completely obsolete*. It is not conforming in any way, shape, or form. http://www.w3.org/TR/2011/WD-html5-20110525/obsolete.html#attr-table-summary I). REPLACE THE FOLLOWING VERBIAGE: "This advice is contradictory. Our preference is that @summary is retained as a fully conforming attribute. This is for several reasons." WITH: "This advice is contradictory for several reasons." WHY: Preferences do not matter in the Decision Policy. Strong arguments based on technical arguments do. J). REMOVE THE CURRENT CHANGE PROPOSAL FROM THE TABLE SUMMARY "CATEGORIES" PAGE to ITS OWN PAGE. WHY: The current page is misplaced. The Change Proposal text was put on an existing "Categories" page. MediaWiki has special dedicated "Categories" pages that auto-magically provide indexes/tables-of-contents based on category metatagging. http://www.mediawiki.org/wiki/Category Putting a Change Proposal on an existing "Categories" page is a mistake. It obscures the index functionality for users. I would suggest removing the Change Proposal contents (not the automagic "Pages in category Table Summary" info at the bottom) from http://www.w3.org/WAI/PF/HTML/wiki/Category:Table_Summary and putting it on new page in the actual Change Proposal directory. The following URL would get a new page in the right spot: http://www.w3.org/html/wg/wiki/ChangeProposals/ReinstateTableSummary Hope some of this is useful. Thank you for your consideration. Best Regards, Laura -- Laura L. Carlson
Received on Monday, 22 August 2011 11:35:42 UTC