RE: FW: CHANGE PROPOSAL: Table Summary

On Wed, 2 Dec 2009, Cynthia Shelly wrote:
> 
> On orientation:  What do you think of Leif Halvard Silli's proposal from 
> last week? 
> http://lists.w3.org/Archives/Public/public-html-a11y/2009Nov/0090.html 

If we were to have an explicit attribute, I'd be more comfortable with 
having it actually cause the table to be sorted, rather than having it 
just declare the sort order. This would lead to a better accessibility 
experience, on the one hand because it'd be more likely to be used, and on 
the other because it'd be more likely to be accurate.

BTW, the attribute that Leaf proposes seems redundant with aria-sort="".


> It seems like using a row or column in the table to define order is less 
> presentation-specific, and more based on content in the specific table 
> instance.  I think this approach has potential, and would like to 
> explore it further.  Does it mitigate your concerns?

I'm not sure to what "it" refers here. Are you proposing removing this 
particular part of the proposed task force recommendation?


> On summary:  I tend to agree that hidden text should be avoided when 
> possible, and I agree that hidden text is often wrong, or allowed to get 
> out of date. The recommendation that summary SHOULD be rendered visibly 
> in authoring scenarios is intended to help mitigate this issue.

Do we have the buy-in from browser vendors to show the summary="" 
attribute by default? If we do, then that dramatically reduces my concern 
with the summary="" attribute. I was assuming we did not, but maybe this 
assumption is incorrect.


> However, I disagree that it's always possible to put everything in 
> visible text.  I have had many discussions with designers on various MS 
> projects who simply won't add extra visible text.  As I'm sure you know, 
> real estate on a high-profile page is very valuable, and it is not 
> always possible from a business perspective to add additional text for 
> accessibility.

Could you show me some pages that have tabular data of a nature 
complicated enough to warrant a table explanation for screen reader users 
(and presumably for other users also), but for which the author refused to 
include visible explanatory text but was amenable to including hidden 
explanatory text? This particular use case is often put forward as an 
argument for summary="", but I am having trouble imagining it. Seeing some 
concrete examples of this would really help.


> But, where would you add the visible text describing the stock quotes 
> table on msn.com or iGoogle?

I don't see any tables on:

   http://moneycentral.msn.com/detail/stock_quote?Symbol=msft&getquote=Get+Quote

There's a lot of misuse of <table> for what should be CSS, <dl>s, or 
other markup, but no actual tabular data. Certainly nothing for which I 
would expect a screen reader user to need a summary="" attribute. Did you 
mean some other msn.com stock quote table?

I did some stock quote searches on iGoogle but got similar results.


> For a non-table example of this in action, try asking Google's designers 
> to add a visible text label to the search box on the home page.  It's 
> currently using hidden text in @title, as is ours.

The right solution for this is not a media-specific attribute, it's 
media-specific CSS. This is the wrong working group for that.

(It's worth noting that we've already added two accessibility features to 
HTML5 for this case: <input type=search> and <input placeholder="...">.)


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


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

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.


> Lastly, I haven't seen many instances of content in @summary in the wild 
> that should be shown to all users. Can you provide some examples?

The e-mail I cited in my replies to Matt and John includes a number of 
such examples.


> I *have* frequently seen poorly written or inappropriate summary 
> content, and of summary content that failed to summarize the structure 
> of the table, as the NBA Tape Recording manual suggests.  I think that 
> is largely due to the fact that this use wasn't really described in HTML 
> 4, and that the layman's definition of the word 'summary' would not 
> include structural data. This proposal attempts to address those issues, 
> which, in my experience, are more prevalent.

I'm certainly happy to add more text to the spec talking about how to 
expose table descriptions and being more detailed in terms of what 
information would actually be useful. The spec right now has several 
examples showing how such text could be exposed, but says very little 
about how it should be written. Do you have any proposed text for 
addressing this particular part of the issue? If so, I encourage you to 
file a bug for that too, since I would be more than happy to add such 
text.


While I object to us (the task force) putting forward a recommendation to 
the working group that suggests that we allow summary="" as defined in 
HTML4, I think many of the other aspects of the draft proposal are quite 
reasonable, and I think we should put these through the normal process 
instead of bundling them all in as one recommendation.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 2 December 2009 01:51:15 UTC