UPDATED: Current state of the summary discussion

For our discussion in the html-a11y meeting on Jan 14, I've attached an updated rewrite of the <table> section of the HTML 5 spec.  I have not updated the change proposal to go with it, as there are still some areas that need further work and discussion.

The numbered sections in this email reflect the action items we agreed to in the meeting of Dec 18, which is summarized below.  I tried to incorporate actionable parts of the following email discussion where possible, but much of it wasn't very actionable.

1) and 2)
The intro to the summary section now reads:

<blockquote>

The summary attribute provides a summary of the table's purpose for user agents rendering to non-visual media such as speech and Braille.

Earlier versions of HTML suggested using summary to provide structural information about the table. This version adds the orientation attributeto allow user agents to derive that information from the table markup.

The information provided by the summary is needed by users who cannot see the table, but would usually be redundant for those who can.  Authors SHOULD use either @summary or <caption><details>  to provide information that is obvious to visual users of the table, but would be difficult to determine by navigating the table cell by cell in an auditory user agent, and which cannot be derived by the user agent from the markup.  Because it can be quite time-consuming to explore a table with a non-visual user agent, authors SHOULD use summary or <caption><details> to give enough information for users to decide if they need to explore the table further, highlighting the general idea that is to be drawn from the table, describing trends, high and low points, and the like.  Authors SHOULD use <caption><details> where a visible, expandable caption is acceptable, but MAY use @summary where business, usability, aesthetic, or other considerations do not allow a visible caption.

 For tables where the relationships are not obvious to users who can see the layout, or in other situations where text describing the structure of the table might be useful to sighted users as well as users of screen-readers and Braille devices, authors SHOULD describe the table using the a caption, legend, or surrounding text instead of, or in addition to, summary. Authors MUST do this in a way that is associated with the table via markup, such that user agents and assistive technology can programmatically determine the relationship. When using @summary or <caption><details> in combination with another technique, authors MUST NOT duplicate the text, but instead use @summary or <caption><details> for the parts of the description that are only useful to users who cannot see the table.

User agents MUST expose summary text in the accessibility API on their platform as specified in the Mappings from HTML to Platform APIs document [note: This document is still under development and does not yet have a stable URL. It will have one before last call].  Non-visual user agents MUST render summary.  Visual user agents SHOULD NOT render summary visually by default in non-editing scenarios.  Visual user agents SHOULD provide a User Interface mechanism to toggle display of @summary and <details>[NOTE: Explore (at a near future date) what, if any, other hidden human-readable metadata should be covered by that UI], and MAY render these features by default in editiing scenarios.

Authoring tools MUST make it possible for authors to add and edit @summary. WSYIWYG authoring tools SHOULD render @summary visually.

</blockquote>
If people like this, I'll work next on moving and reworking the <details> example for better flow.

3) I left orientation, rather than switching to definesorder.  After deeper reading, further consideration, and discussion, I've realized that orientation is different than order.  Orientation is about whether the user should read the table primarily across rows or down columns. Sorting/order is about whether a table is ordered by a particular row or column.  Unsorted tables can still have orientation.

However, tables with a strict orientation are not that common.  In many tables we looked at, the orientation was based on the task.  Because of this, I've added a third value to orientation:  none.  This is the default value.

Here is the orientation text
<blockquote>
The orientation attribute can have the values horizontal,vertical, or none, which indicate whether the table should be read in horizontally (by row), vertically (by column), or that there is not a clear directionality to the table. none is the default value. Auditory user agents MUST read the table according to this attribute, across rows when it is set to horizontal and down columns when it is set to vertical. User Agents MAY make use of the orientation when splitting tables, such as for small screens or printing.  See the National Braille Association's Tape Recording Manual [http://www.rfbd.org/about.htm] for further explaination of rows and columns.
</blockquote>

Here are some example tables (thanks Wendy)
*      WebAIM summary example<http://www.webaim.org/techniques/tables/data.php#summaries>
*      Consumer credit<http://www.federalreserve.gov/releases/g19/current/g19.htm>
*      Foreign Transactions in Currencies<http://www.federalreserve.gov/econresdata/releases/secholdtrans/current.htm>.
*      U.S. Air Traffic Carrier Statistics<http://www.bts.gov/xml/air_traffic/src/index.xml#TwelveMonthsSystem>


4) Deleted the cells API changes.  Wendy has agreed to spend some time defining what information AT needs from a table, and where the holes are.  Once that work is done, we'll explore API changes that will fill the holes, and make things that are currently possible but difficult easier for AT to determine.  The areas we discussed where there are obvious holes are columns, getting cells in situations where there are rowspans or colspans, and major and minor headings.  The cell API was intended to address major and minor headings, but we think these need to be addressed as part of a larger effort to understand what AT needs from tables.  We need some volunteers to help with this part of the effort.


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