- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 9 Dec 2009 18:35:57 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
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 UTC