W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2009

RE: FW: CHANGE PROPOSAL: Table Summary

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 10 Dec 2009 12:50:58 +0100
To: Cynthia Shelly <cyns@microsoft.com>
Cc: Ian Hickson <ian@hixie.ch>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20091210125058410215.81a8236a@xn--mlform-iua.no>
Cynthia Shelly, Wed, 9 Dec 2009 23:32:41 +0000:
> inline
> 
> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Tuesday, December 01, 2009 5:51 PM

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

A similarity between aria-sort and definesorder is that the reading 
order - for the screen reader - would be a derived effect: If the 
@definesorder attribute that I suggested informs the screen reader that 
the table is sorted according to "column 2", then the table will be 
read downwards, row by row. If @aria-sort instead - or in addition- 
informs the screen reader that "column 2" uses ascended sorting, then 
you get the same result - with regard to how the table should be read.

In more detail:

I ended my proposal by saying that the type of sorting 
(descending/ascending/numerical/alphabetical) had to be defined in 
another way. It seems like aria-sort="", OTOH, defines the type of 
sorting. So, in this regard, aria-sort gives a little bit more 
information. Technically, there is also a difference: Aria-sort will be 
placed in the top heading cell of the column or row according to which 
the table is sorted. Whereas definesorder="" would take as value the 
@id value of the column/row that carries the sort order. I also said 
that if the author doesn't know which column defines the order, he 
could also set definesorder="" to point to the <colgroup> element. If 
there is no <colgroup> element, then there is only one colgroup - the 
entire table. And in that case one should also be able to do this: 
<table definesorder="this" id="this"> - but perhaps that would be 
absurd ...

Illustrating aria-sort and definesorder in the same table:

<table definesorder="column2">
	<col id="column1" /><col id="column2" />
<tr><th>Column 1 head<th aria-sort="descending">Column 2 head
</tr> [ ... ] </table>

Aria-sort can take as value "descending", "ascending" or "other". A 
problem with aria-sort that I see is that it requires more from the 
author. One must know what kind of sorting that is applied.

As the example above shows, it could be possible to use both 
definesorder="" and aria-sort="" in the same table.

Using aria-sort="" when definesorder="" points to a <colgroup> could 
perhaps be confusing, as aria-sort="" would be placed in a column 
header.

Some tables are not sorted at all - the data are just placed there in a 
accidental order. It doesn't seem like aria-sort provides any solution 
for those. But even if the data has an accidental order, one could 
still say that a particular column defines the order. For example, if 
the data is just entered in the order they appear, row by row, then it 
seems like the first column should be set to define the order.
 
>> 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>

This is as I thought it would work, yes.
-- 
leief halvard silli
Received on Thursday, 10 December 2009 11:51:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:41:57 GMT