RE: draft of summary change proposal

In the details of how user agents should handle summary it is stated in part:

Visual user agents MUST NOT render summary
visually in non-editing scenarios, and SHOULD render summary visually in editing scenarios. Non-visual user agents MUST render summary.

I think the first sentence is better stated as:

Visual user agents should NOT render summary
as part of the rendored content by default in non-editing scenarios, and SHOULD render summary visually in editing scenarios. Non-visual user agents MUST render summary.

Must is changed to should because there are valid scenarios when the appropriate visuall user agent may want to display summary text.  Suppose I have a mode in my user agent where I am displaying content in an alternative view, perhaps similar to how a screen reader may display text.  Various accessibility toolbars do this today and in such scenarios display of the summary text is valid.  This is just one example.

The second visually is changed to as part of the rendered content by default because a user agent may choose to display this info visually in some other fashion e.g. if the user indicates a request to see such info.

Summary for example may assist certain people who for various reasons want some assistance in understanding the table but who can still see the data being presented. Here again the visual user agent should not be discouraged from making such available on request.

From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Cynthia Shelly
Sent: Wednesday, November 11, 2009 3:57 PM
To: public-html-a11y@w3.org
Subject: draft of summary change proposal

Here is a draft of a rewritten table section to deal with summary.  It's still fairly rough.

This is an attempt to make more information available to assistive tech from the markup, so that less is required in summary.  I would particularly like feedback on the approach, and on ways that this goal can be achieved.

It reduces the scope of what summary is to be used for, by including

1)      An orientation attribute on the table element.  This can be used to AT to describe the reading direction of the table.

2)      Methods on the cell API to get collections of headers and headergroups

cell . cellColumnHeaders
Returns an HTMLCollection of column headers associated with this cell.
cell . cellColumnGroupHeaders
Returns an HTMLCollection of column group headers associated with this cell.
cell . cellRowHeaders
Returns an HTMLCollection of row headers associated with this cell.
cell . cellRowGroupHeaders
Returns an HTMLCollection of row group headers associated with this cell.

QUESTION:  are there implied row groups and col groups based on rowspan and colspan on th?  Should there be?

It describes what user agents, both visual and non-visual should do with summary.

It also includes an example table, based one from Wendy Chisholm.  I changed it a little, and would like feedback on that as well.

I still need to write guidance for validators, but wanted to see if this approach works for people before going any farther.