RE: FW: CHANGE PROPOSAL: Table Summary

On Wed, 9 Dec 2009, Cynthia Shelly wrote:
> 
> > 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?
> 
> <cyns>
> Sorry, "it" meant Leif's proposal.  If we replaced @orientation with
>         <table definesorder="price">
>         <col id="price" />
> 
>         <table definesorder="price">
>         <tr id="price">
> Would you find that more acceptable?
> 
> I'd like to flesh out his idea in further discussion with the group, 
> look at edge cases, what happens with nesting, that sort of thing.  It 
> may work better than @orientation.
> </cyns>

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. I don't see much 
point in an attribute that simply duplicates the functionality of the 
aria-sort="" attribute.


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

I presume the examples below are intended to be these? It's unclear.

> > 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.
> 
> <cyns>
>
> I've been through many of those examples.  There are summaries that are 
> less than good.  There are quite a few that I think are useful to users 
> who can't see the table.
> 
> Let's look at this one 
> http://philip.html5.org/data/table-summary-values-dotbot.html (not the 
> whole thing but the first several pages).
> 
> "Calendar" (multiple references in a variety of languages). This could 
> be a caption, but it doesn't need to be visible.  Sighted users can see 
> that this is a calendar.  There may not always be room in the layout for 
> the word calendar, and there's a valid design argument that it's 
> unnecessary and would complicate the page, perhaps reducing usability or 
> brand appeal.  Going through the table to determine that it's a calendar 
> is a lot of work for a screen reader user, so having a summary of 
> "calendar" lets them know that they can skip it if they don't need to 
> look at the calendar right now.

This sounds nice in theory, but I looked at four random pages from the 
set, and none were in English -- so having an English-language summary is 
clearly not actually helping the user.

I then explicitly looked for an English-language page, and on that page 
there was a summary ("Calendar") and a caption ("April 2008"). The summary 
is redundant in that case -- even an AT user who can't see the table will 
immediately know it's a calendar just from the caption. In fact, this 
applies to all the Western-language pages I found with summary="Calendar".

Furthermore, "Calendar" _is_ a caption. It belongs in <caption>. If 
there's a need for media-specific presentation, then we should achieve 
that at the CSS level, using one of the many well-established techniques 
or using new techniques such as media queries. Having it in a summary="" 
means that its value isn't updated when it should be (e.g. as in all the 
examples I randomly looked at), and it isn't accessible to users who don't 
have ATs, but may need them.


> "Monthly calendar with links to each day's posts".  Very useful.  Now I 
> know how to navigate to the posts for the month.  If I'm not interested 
> in navigating right now, I can skip this calendar.

I looked at the first three and last three pages that had this. One no 
longer had a summary="". One had the table immediately below a heading 
saying "December 2009", which is redundant with the summary, as in the 
examples I mentioned above with summary="Calendar". One was on a page that 
wasn't English, and thus is further evidence of my point that summary="" 
leads to authors not updating the text and thus making it less useful 
for users than having nothing. One had both of these -- it was on a page 
that wasn't English _and_ the table already had a caption. One was flat 
out wrong as well as being redundant with the visible heading (it was a 
calendar of events, not a calendar of posts). And one had explanatory text 
before the table visible to all as well as the table having a caption.

I don't think "Very useful" is an accurate portrayal of these summary 
values.


> " Telerik RadCalendar title and navigation controls"  also useful.  I 
> know it's a calendar with controls.  If this is a site I use often, I 
> probably know how the telerik RadCalendar works, and will know exactly 
> what to do with this thing.

Please look at the first of the pages that had this summary:

   http://www.fangraphs.com/wins.aspx?date=2003-03-31&team=Giants&dh=0&season=2003

It has _sixteen_ data tables, none of which has a summary="". The table 
that _does_ have that summary has five cells, four of which have nothing 
in them but an image in a link with the alt texts being "<<", "<", ">", 
and ">>" respectively, and the middle cell being a caption for the actual 
calendar which is actually a table that is itself in a cell in the other 
row of the table whose own summary is just "Telerik RadCalendar instance".

I grant you that if you use this site often, you might be able to guess 
how to navigate the calendar widget based on this. However, I think it's 
rather a stretch of the imagination to suggest that the summary="" on that 
page is doing anything to truly improve accessibility for anyone.


> "Navigation", "Navigation header", "Navigation footer", "Banner", "Text 
> Ad" and similar.  Again, I know what this table is for, and that I can 
> skip it if I don't want to navigate.  Sighted users can tell what these 
> are without the text, and the text would be clutter to them.  There are 
> some less good examples ("buttons"), but that still gives me some 
> information.

I looked at two of the pages with "Navigation" as the summary randomly, 
and both were misusing tables for layout purposes, and thus would be more 
usable to users if either (a) they triggered the AT layout heuristics, and 
thus didn't report the summary="" at all, or (b) didn't use tables in the 
first place.


I'll stop now, but my point is that in truth, even summary="" values that 
look like they have a chance at being useful aren't actually useful.

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

Received on Thursday, 17 December 2009 19:52:03 UTC