Current state of the summary discussion

Janina asked me to provide a summary of the discussion of the @summary attribute for table, to aid us in our discussion on the HTML-a11y call.

Here is the most recent draft of the change proposal  http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18%2C_2009

Big long discussion with Ian.  http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0056.html

Interesting points to bring out
1)

> Again, would it help if the proposal recommended using visible text,

> except in situations where that won't work, due to business or design

> concerns that make the visible text problematic?



That's what the spec does now, including suggesting at least one

mechanism that hides the explanatory text by default, while making it

accessible to all users (namely, using <details>).



<cyns>

If you're ok with explanatory text being hidden in <details>, why do you object to it being hidden in summary?  How do you see them as different?  These seem the same to me, except that summary has legacy support, so I'd be happy to better understand your thinking here.



There's a difference between recommending using visible text and issuing a validation warning when you using hidden text.  It's the validation warning that people object to.  It says that using summary is a bad thing to do, and for people who spend a great deal of time and effort convincing developers to do accessibility work, including adding summary, this makes life very difficult.  I suspect that most of the objections would go away if the validation warning went away, and there was just advisory text saying that it's better to use visible text when you can.



What if we got rid of the validation warning, positioned <details> and @summary as mechanisms for including non-visible text, and then discussed the value of including visible text, and situations where authors might not be able to?  This seems like something we could all live with, which is all that's needed for consensus.

</cyns>



Is this a position we can live with?  What is required to get official consensus on that?



2) the cell API additions
cell . cellColumnHeader<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#dom-tdth-cellcolumnheader>s
Returns an HTMLCollection<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#htmlcollection-0> of column headers<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#dom-tdth-column-headers> associated with this cell.
cell . cellColumnGroupHeader<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#dom-tdth-column-group-header>s
Returns an HTMLCollection<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#htmlcollection-0> of column group headers<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#column-group-header> associated with this cell.
cell . cellRowHeader<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#column-header>s
Returns an HTMLCollection<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#htmlcollection-0> of row headers<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#row-header> associated with this cell.
cell . cellRowGroupHeader<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#dom-tdth-column-group-header>s
Returns an HTMLCollection<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#htmlcollection-0> of row group headers<http://lists.w3.org/Archives/Public/public-html/2009Nov/att-0488/table2.html#column-group-header> associated with this cell.

<cyns>

> Another goal of this proposal was to make it necessary to use summary

> less often, by exposing header relationships and direction in markup.

> Summary in HTML 4 was kind of a catch-all for describing the table, as

> one would do on a tape-recording of a book.  Obviously, HTML can encode

> a lot more structural data than a voice recording.  One of the goals of

> this proposal was to move some things out of summary, so that it would

> less often be necessary to have a hidden summary.  That's the point of

> @orientation and of the additions to the cell API, allowing the

> structure of the table to be exposed more easily to AT, so it does not

> need to be described by the author.

</cyns>

<hixie>

I have no a priori objection to exposing the table structure as a DOM API.

That should, IMHO, be filed as a separate bug, since as far as I recall it

hasn't been through that process yet.



However, I don't think the cell API is a good way to expose the table

structure to ATs -- ATs should just use browser/OS APIs, not Web DOM APIs.

</hixie>

Other thoughts?



3) Near the bottom of the post, I went through one of the sets of summaries found in a Web crawl.  I found most of them to be useful, even though they didn't fully meet the recommendations in WCAG. Is this the data people wanted?  I can go through the rest of the sets if that would help.

Other discussions

http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0026.html
I plan to change @orientation to something more like this proposal, which points to a row or column in the table to define the orientation of the table. Do people like this idea?  I don't fully understand the concerns about how this relates to aria-sort, and would like to explore further.  Ihttp://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0064.html  It has been suggested that this should be a different change request. Is anyone interested in helping on this?

Displaying summary values in authoring scenarios, but not otherwise.

*         http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0058.html (for)

*         http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0059.html (against content-editable, perhaps ok for authoring tools?)

*         http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0066.html toggling a variety of hidden-meta-data settings, based on editing scenarios, or perhaps a UI mechanism for toggling?