FW: [html] Summary draft

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'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.

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.


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 element http://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?

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