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

(unknown charset) Re: CHANGE PROPOSAL: Table Summary

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 9 Dec 2009 18:35:57 +0100
To: (unknown charset) Ian Hickson <ian@hixie.ch>
Cc: (unknown charset) HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20091209183557385617.1a4f8107@xn--mlform-iua.no>
Ian Hickson, Mon, 7 Dec 2009 15:26:51 +0000 (UTC):
> On Mon, 7 Dec 2009, Leif Halvard Silli wrote:
>> 
>>> [...] I think a better way to get data 
>>> about this would be a set of usability studies of Web authors followed by 
>>> double-blind studies of the pages they write.  For example, take six to 
>>> nine Web developers, and give them the task of marking up some Web pages 
>>> that include particularly complex data tables in an accessible way 
>>> that is 
>>> still aesthetically pleasing to them. The developers would be split into 
>>> three groups, one being given instructions on using summary="", one being 
>>> given instructions on writing paragraphs around the table, and one being 
>>> given no instruction at all. [...]
>> 
>> What would this find out?
> 
> The goal I had in mind was primarily to find out whether accessibility is 
> improved or harmed by summary="" being in the language and advocated.

(A third option is that keeping summary makes no difference.)

This sounds like a policy effect evaluation - quantitive research. I 
would have preferred evaluation of mechanics - qualitative research. 

For instance, take the <caption> example in the HTML 5 draft:

<caption> 
<p>Table 1. 
<p>This table shows the total score obtained from rolling two 
six-sided dice. The first row represents the value of the first die, 
the first column the value of the second die. The total is given in 
the cell that corresponds to the values of the two dice. 
</caption>

The clue in WCAG 2.0 is not specifically @summary, but whether the info 
can be "programmatically determined". There are a number of screen 
readers that support @summary. So, by a) placing the second paragraph 
in your caption example inside a @summary, b) setting up some user 
agents for testing purposes so they work as we want them to, c) asking 
some blind users to test the original in the draft versus a version 
with the text inside @summary, we should be able to find out how 
important it is that the summary can be programmatically determined.

That way we would for instance to, with more authority, agree or 
disagree with WCAG 2.0 when it says: [1]

]]
There may also be cases where it may be a judgment call about what 
information should appear in text and what would need to be directly 
associated, and it may be most appropriate to duplicate some 
information (for instance, in an HTML table, providing the summary both 
in the paragraph before the table and in the summary attribute of the 
table itself). However, wherever possible it is necessary for the 
information to be programmatically determined rather than providing a 
text description before encountering the table.
[[

[1] 
http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/content-structure-separation-programmatic#content-structure-separation-programmatic-intent-head
-- 
leif halvard silli
Received on Wednesday, 9 December 2009 17:36:33 GMT

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