Re: [html] Summary draft

On Sep 14, 2009, at 4:13 PM, Cynthia Shelly wrote:

> This conversation was started on the wai-xtech list, but it’s time  
> to move it over here.  The draft below is based on an HTML 5 draft  
> of about 1 month ago, and is an attempt to find a middle ground on  
> @summary.  One goal was to clarify when a “hidden” summary, only  
> used by those who can’t see the relationships implied by table  
> layout, should be used, and when a visible description of the table  
> (such as in a caption or surrounding text) is more appropriate.  It  
> also uses ‘guidance to conformance checkers’ rather than obsoleting  
> the @summary attribute.

I have not yet read the draft, but some preliminary comments are below:

>
> I’m also intrigued by the suggestions for auto-generating summary  
> text based on headers, axis, etc. in the thread on “good summary  
> text.”  http://lists.w3.org/Archives/Public/public-html/2009Sep/0492.html 
>   This is an area that deserves more research.   The output of such  
> a generator, I think, makes most sense in a summary attribute,  
> separate from surrounding text and caption, since it will often be  
> obvious to users who can see the layout of the table.  This would be  
> a very useful authoring tool feature. Once the idea is proven, then  
> perhaps that functionality could be moved into browsers, and summary  
> would no longer be needed.  However, I don’t think we’re there  
> yet.   The table discussed in that thread is also a good table to  
> use as an example.

If autogenerated summary information is put into the markup, then  
there needs to be a way to distinguish it from a handmade summary. If  
a user agent can automatically generate a summary itself, then it  
should ignore a provided autogenerated summary (because the UA's  
algorithms may be more effective, more modern, better  
internationalized, etc as compared to whatever was used at the time  
the document was made) but possibly not a handwritten summary.

>
> Questions on this draft:
> 1.       Is the distinction between clear between a table that  
> requires a general description of how to use it for all users, and  
> one that will be immediately useable to sighted users, but not to  
> those who cannot see the layout of the table?  If not, what sorts of  
> information would be helpful to make that clear?
> 2.       I’d like to hear from those on the list who have general  
> objections to hidden metadata. In general I agree that developer  
> psychology is such that things the developer can't see are more  
> likely to be missed or allowed to get out of date, and that it’s  
> good to try to avoid them.  But, I think there are use cases where  
> they are needed anyway, and in those cases we need to rely on  
> authoring tools to expose them in a reasonable way to developers.   
> Alt text is one example, and one where some authoring tools do a  
> decent job.  I think summary falls into the same category.  So, for  
> me, avoiding hidden things is more of a guideline than a hard-and- 
> fast rule.  In my opinion, describing purely visual information is  
> such a use case.  Alt does that for graphics, summary does it for  
> table layout.
> 3.       Is guidance to conformance checkers a good way to approach  
> this?  Describing and summarizing tables is a fairly subtle area of  
> markup, and it seems that conformance checkers could be very helpful  
> in educating authors here.  However, the idea of marking summary  
> obsolete to achieve it seems to say that using summary is a bad  
> idea, and that is what is causing friction with accessibility  
> advocates.  I think this approach is a reasonable middle ground, in  
> that it will still cause a conformance warning.

I'd like to hear input from the validator.nu developers on this. At  
first glance, it seems like a warning will be generated every time a  
table appears.

>
>
> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On  
> Behalf Of Cynthia Shelly
> Sent: Thursday, August 13, 2009 3:41 PM
> To: wai-xtech@w3.org
> Subject: [html] Summary draft
>
> http://dev.w3.org/html5/pf-summary/Overview.html#the-table-element
>
> Here is an attempt at finding a middle ground on @summary, an  
> attempt to continue the dialog about this accessibility attribute.  
> It is not perfect, and would benefit from further discussion.  Most  
> of the edits are in 4.9.2 The table elementhttp://dev.w3.org/html5/pf-summary/Overview.html#the-table-element
>
> The highlights of this draft are this
>
> 1) It leaves the summary attribute in, using the HTML 4.01 text but  
> edited to fit the sentence format of the HTML 5 spec.
>
> 2) It adds summary to the content attributes and DOM interface.  I  
> added it at the end of the DOM interface, not sure that's the right  
> style.  I also added it to the table API as table.summary,  
> table.createSummary, and table.deleteSummary, but I'm not sure  
> that's really needed.  Perhaps normal attribute accessors are enough?

table.summary (from DOM2 HTML) is already defined, although in an odd  
place:

http://dev.w3.org/html5/spec/Overview.html#dom-table-summary

table.createSummary() and table.deleteSummary() are new inventions and  
seem unnecessary to me. You can create a summary just by setting  
table.summary, and delete the summary by setting table.summary to the  
empty string, or by using removeAttribute(). I do not think these  
should be added.


>
> 3) It adds some text and a code example donated by Matt May from his  
> and Wendy Chisholm's book Universal Design for Web Applications.  I  
> still need to add the working table example, but do have the code  
> snippet in there.
>
> 4) It describes at some length when to use summary vs. the  
> techniques in Ian's draft.  This basically boils down to using  
> summary for things that are obvious if you see them, and confusing  
> if you can't.  Ian's examples are retained with minor edits to the  
> surrounding text.  The text is still a bit clunky, but I think it  
> suffices to open the dialog.  I also notice that there is a similar  
> example under the caption element.  It reads a bit strangely to have  
> it in two places, and would be nice to consolidate them.  I also  
> plan to submit Ian's examples to WCAG, but haven't yet done that.
>
> 5) It adds some discussion of Platform Accessibility APIS and  
> programmatically determined under WCAG, and when ARIA might be  
> needed to make either of these work as expected.  I also added aria- 
> describedby to the example that uses a paragraph before the table.   
> See http://www.w3.org/TR/WCAG20/#new-terms for a definition and  
> discussion of programmatically determined under WCAG.
>
> 6) It adds a section on Guidance for conformance checkers, which  
> suggests warning when any of these techniques is used, describing  
> the difference between summary and the others, and also for any  
> table which uses none of the techniques.  This essentially means  
> warning on every table, which I'll admit seems less than ideal.   
> This is modeled after the guidance for alt in the image  
> attribute.    I think this allows removing summary from the obsolete  
> section, but still gives the opportunity to provide guidance to  
> authors about when to (and not to) use it.  http://dev.w3.org/html5/pf-summary/Overview.html#guidance-for-conformance-checkers-0
>
> 7) It removes summary from the obsolete section
>
>
>
>
>
>