RE: Current state of the summary discussion

I wanted to capture the outcome of the telecon, before I go on vacation.  This is what I understood from the discussion on the telecon.  Did I miss anything?


1.       Treat @summary and <details> the same, as both are hidden metadata.  Remove the validator warning for summary, but include strong spec text encouraging the use of visible text (caption, etc) when possible, and describing specific scenarios in which it might not be possible.  The validator warning is the blocking issue for many of the accessibility advocates.

*         Janina had an interesting point:  being hidden isn't an accessibility feature.  Being hidden is a feature for everyone else, so that this text doesn't clutter up their UI.  Chaas added that not cluttering the UI can be an accessibility feature for users with cognitive disabilities.  I'll try to work this concept into the introductory text somehow.

2.       Add a SHOULD or MAY for browsers to have UI to allow users to toggle showing summary (and details?).  The default would be not to show.  Explore (at a near future date) what, if any, other hidden human-readable metadata should be covered by that UI.  This seems like it could get us past the issue of hidden metadata being generally harmful, which has been a blocker for many people.

*         Modify the existing SHOULD clause about authoring scenarios to make use of the above mechanism.  Consider changing to a MAY.

*         In threads after the call, the suggestion was made to  Would adding a <summary> inside <caption>, while still allowing the @summary for back-compat. In many ways, this is the same as details, and could be subject to the same UI toggle.   However, I think it would be easier to explain to people that summary changed from an attribute to an element, and would be less disruptive to regulations or existing training.

3.       Further develop the idea of @definesorder, and how it might interact with aria-sort.  This will be a separate change proposal.  Wendy Chisholm has offered to help with this work.  Leif, your help would be most welcome as well.

4.       Further explore the cell API, or other ideas that might solve the same issues.  Wendy Chisholm has offered to help with this too.

Ian, if we did #2, would that alleviate your concerns about users not being able to easily show the hidden text?  If we combined #1 with #2, would that be something you could live with?   Does adding <summary> make any difference?

I have an action item for Jan 14 to submit an updated change proposal along these lines, working with Wendy Chisholm.

From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Cynthia Shelly
Sent: Thursday, December 17, 2009 7:57 AM
To: HTML Accessibility Task Force
Subject: 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?