Re: FW: CHANGE PROPOSAL: Table Summary

Sorry for any mis-attribution of comments inline.

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

Is this kind of 'sorting' mechanism necessary at all? And if so should
it be separate disambiguated from @summary. If a sorting mechanism is
needed I think this would be best. A sorting mechanism could be useful
for dynamically generated tables I guess.

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

I think this would be a good idea also.

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

Well I don't buy the argument that because @summary is hidden (visually)
it is harmful to /any/ user group. In fact what is actually harmful is
the argument itself.


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

I agree, examples like this would be useful. It is an interesting edge
case actually.

Cheers

Josh

Received on Thursday, 10 December 2009 10:13:49 UTC