Re: [Text] Resuming Table Summary Change Proposal Discussion

Hi Laura,

Many thanks for your excellent and substantive feedback. I will be doing
some more work in the CP later on in the week and I look forward to
going through it in detail.

Cheers

Josh

On 22/08/2011 12:34, Laura Carlson wrote:
> 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 Tuesday, 23 August 2011 14:54:43 UTC