Re: table/@summary, Re: ISSUE-4: Versioning, namespace URIs and MIME types

Ian Hickson 2009-02-18 00.10:
> On Tue, 17 Feb 2009, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> ... In fact, the main argument against keeping <table
>>> summary=""> is that legacy content has abused it so badly
>>> that it is unusable. So the argument is effectively the
>>> same one here.
>> Did you look at James' latest mail?
>> 
>> http://lists.w3.org/Archives/Public/public-html/2009Feb/0379.html
> 
> Yes. [...] What we really need is more solid and objective
> data. Usability studies are notorious for showing that users
> don't actually recognise usability problems that they are 
> exposed to. I can't count the number of times I've seen users
> in usability studies say things that flatly contradict the
> actual measured facts of their own behaviour and experiences.

W.r.t. "solid and objective data", how about data on this:

1. Whether, *in an ideal situation*, users benefit from getting a 
table summary by the touch of button, or not. Both usergroups 
(users of visual and non-visual UAs) should be tested (and 
compared) - as it has been claimed that both groups would benefit 
equally.  The testers should get to know in advance how to use the 
summary feature, and they should mechanically press the "summary 
button" - they should not rely on discoverability or on any "try 
and see if there is a summary". (One way to test it: use the 
@title attribute of the .)

	How to test: Through some kind of speed test. E.g. how fast - 
with and without such a touch-of-a-button summary feature - do 
users judge whether table x, y, z is relevant to a particular 
subject? And how fast does a user navigate to a particular info 
inside a table when a summary explaining how the table is designed 
is available, compared to when it is not. Both tables inside texts 
and lone tables on lone pages should be tested. As well as tables 
without caption. (Focus is not the very summary attribute, but 
rather the usefullness of an fast available summary feature.)

2. In another test, speedtest the effect of table summaries 
directly in the normal text flow. Here it would also be neccessary 
to compare negative/postive reactions from both usergroups. 
Eventually, combine this test with the above test.

3. Give some authors a document containing a table, a caption, a 
summary and a related text preceding the table - all of them with 
style="display:none". Ask them to remove the "display:none" from 
all elements they would like to show to visual User Agent users.

4. Going more directly on @summary: data on how simple it is for a 
user to discover that a table has a @summary - given that the 
situaton is that most tables don't have any. Here one could 
perhaps stress test some users. Ask them to consume a lot of 
tables, where some of them have a @summary attribute and see if 
they detect them. Prepare the testers in advance. If they don't 
detect them, then it is either an argument for removing or 
improving the discoverability of the summary feature (and then 
retest).

5. Data on whether presence of @summary helps anyone in their job 
performance, their study, their research, their soccer table 
reading, their internet banking reading? Stories from real life. 
Helping a few can be a great benefit.
-- 
leif halvard silli

Received on Wednesday, 18 February 2009 05:25:35 UTC