RE: FW: CHANGE PROPOSAL: Table Summary

inline

-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch]
Sent: Tuesday, December 01, 2009 5:51 PM
To: Cynthia Shelly
Cc: HTML Accessibility Task Force
Subject: 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="".

<cyns>
I didn't think it was sorting, but instead using a particular row or column as a sort of super-heading that also defined the reading order of the table.  Leif, if you are following this thread, could you describe how you think the screen reader would read this?
</cyns>

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

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

<cyns>
This says to show it by default *in authoring scenarios*.  For a current browser, that would generally mean on things that are content-editable.  For a visual  authoring tool, it would render in the editing/design surface, but not in previews.  I'd like to get general agreement here that this is a good idea, and then I'll happily take it to the IE team and various authoring tools teams.  It sounds like you think it's a good idea.  Is that correct?  Anyone else?  Anyone hate it?
</cyns>

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

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

<cyns>
Add the stock gadget to my.msn.com or iGoogle.  The current renditions are misusing divs, though they have been tables in the past.  If you were going to describe the structure of that table, where would you put the text?  How big can the gadget grow?  They're usually constrained by business requirements.  Do you describe the table and cut a line of data?  Sports scoreboards are another example.  At various times, MSN's home page has had a sports scoreboard on it, usually a gadget that is a smaller version of something like this one on yahoo  http://rivals.yahoo.com/ncaa/football/stats.  (I'm not a sports fan, so I may not be finding the best examples here.  Matt, can you point to some others?).  Adding an explanatory paragraph to this page would mess up its design.  How about the box scores on http://sports.yahoo.com (lower right).  During various parts of the year, box scores are featured prominently on portal sites, sites where every pixel is worth a lot of money, and where design is an important part of branding.  Newspaper sites do this too.
</cyns>

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

<cyns>
However it is implemented, the text providing the accessible name is not going to be visible. It just doesn't make sense in the design.  The role isn't visible either, and it still needs to get a name from somewhere.  You could use aria-label to tie the name to the search button or the Google (or Bing) logo.  But, is that text really labeling the control?    This is an example of accessibility running into design and business.  Look at both our sites.  They're using hidden metadata to get past those conflicting requirements.

And, FWIW, I like <input type=search>.  I would expect <input placeholder="..."> to map to value, not name.  It might work to have it map to both, I'd need to think more about that.
</cyns>
> 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>

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

<cyns>
Anyone have other ideas on how to accomplish this?  I'm very open to input on this.

Once we have agreement on the various parts of the proposal, I'll break them into separate bugs.
</cyns>

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

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

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

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

"Search results".  In this case, something visible would be better.  I'd use an <h1>-<h6>, and probably wouldn't use a table at all.  But, if there is a layout table full of search results, having this hear makes it easier to tell what's going on.

"main content", "main".  We're probably dealing with a layout table here, which is less than ideal.  Sighted users can tell from the layout of the page that this is the main content.  Now non-visual users (including me, looking at this summary of summaries) can too.  Current recommendation is to use a <h1>-<h6> for this, and hide it with CSS, since sighted users will find it unnecessary clutter.  Having this is better than not having it.

"layout table".  This is no longer recommended, but was recommended by a some people to improve accessibility long ago when screen readers didn't know how to deal with tables.  I agree this is not useful, but I don't think it's harmful.  However, this variation is pretty useful, and I saw some other similar ones.
" Layout table: Main table. The first row contains a USDAFS link and a service wide drop-down navigation. The second row and third rows contains the forest name and search engine. Below this are two cells. The left cell contains the site navigation. The right cell contains the content of the page."

Here are some summaries that I think are useful.  Some are even pretty good, if not a perfect match to the recommendations:
" Shows where you are in relation to the home page of the site"
" Overview of additional product characteristics"
" Mp3 Download lyrics - Artists by letter: a..z 0..9"
" Some more (technical) info about this picture"
" Table for professional and validation links and standards of conformance for web page."
" The download table links to the download of the package and a file overview. In addition it gives information about the package size and the installed size."
" This is a table of location information for the nearest beach, airport, railway, highway intersection, ferry port and car necessary"
" This table display a list of bookings for the specified date range. The columns are: Date (only in week or monthly view) Start, End, Event Name, Location, Group"
" This table displays the Organisation's logo and two levels of the site's navigation structure"

Some of these would be ok in a caption, but most aren't really needed by sighted users, and adding  text before them could mess up the design of the page.
</cyns>

> 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.
<cyns>
I'll add that to my next draft.
</cyns>

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.

<cyns>
I'm fine with that once we get to the editing phase.  I'd like to keep discussing them together while we're still working on engineering.
</cyns>
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 9 December 2009 23:36:06 UTC