RE: FW: CHANGE PROPOSAL: Table Summary

Ian,

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

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. Of course it doesn't catch every possible instance, but it will help.  

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.  In an article with data tables, yes, this might be possible, even in cases where it is somewhat redundant.  But, where would you add the visible text describing the stock quotes table on msn.com or iGoogle? There is also a fairly prevalent design aesthetic that finds such text to be unusable clutter, so adding extra text may go against design or branding requirements.  When branding and business needs go head-to-head with accessibility, accessibility usually looses.  Hidden text makes it possible to meet both requirements.  Would it help if the proposal used this sort of example to describe situations when it would be better to use summary versus one of the visible mechanisms?

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. I suspect you won't have any better luck than I did. Summary provides the same sort of mechanism, to allow both accessibility and design/business goals to be met, via hidden text.  In most cases, it shouldn't be necessary, but in some cases it is.  

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?  I would feel more comfortable also discussing the goal of eliminating redundancy in other texts where these issues don't exist, but I think it's less of an issue.  In cases where the page author finds it problematic, then it can be thought of as a design requirement.  I do think that having a programmatic association is important, and most of your examples do.  The nearby-paragraph example can be made to easily with ARIA, so that shouldn't be an issue either.

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. Leif's proposal is somewhat better, in that it uses structure already in the table to define the direction. I think this approach strikes a middle ground, where there should be less need for summaries in practice moving forward.  

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

Thanks,
Cynthia

-----Original Message-----
From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Ian Hickson
Sent: Tuesday, December 01, 2009 12:40 PM
To: Cynthia Shelly
Cc: HTML Accessibility Task Force
Subject: Re: FW: CHANGE PROPOSAL: Table Summary

On Tue, 1 Dec 2009, Cynthia Shelly wrote:
>
> Can we please put this on the agenda for 12/10?  I have a prior 
> engagement this week, so I won't be able to discuss it on 12/3.
>
> http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18%2C_2009

I'm a little uncomfortable with this change proposal.

Specifically, I feel two of the requests -- adding summary="" and 
orientation="" -- are actually likely to cause harm to accessibility 
overall rather than help it.

Re summary="": I think it would be better to encourage authors to always 
provide visible text explaining tables, since this would would be more 
likely to be correct, and would benefit more users. We've seen that when 
accessibility information is not visible to authors by default, they tend 
to screw it up, so having help information only visible to screen readers 
is unlikely to help accessibility; and we've seen that for the few authors 
who do provide helpful summary="" text tend to put values in that 
attribute that would be useful to more than just users of accessibility 
tools, causing other users to miss out on potentially useful information.

Re orientation="": It seems dangerous to have features that are so 
media-specific, since again, authors are unlikely to use it correctly. It 
seems better for user agents to use the information that can be derived 
from the table model to determine whether the table is row-major or 
column-major. If we keep this in the proposal, we should at least include 
a few examples of tables where the UA would be unable to accurately 
determien the right reading direction, especially giving examples of 
orientaton=vertical.

Since I will be unable to attend the call on 12/10, could I request that 
we discuss this by e-mail instead of on the teleconference?

Cheers,
-- 
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:18:16 UTC