Re: Things in HTML that I disagree with (Was: evidence of harm)

On Thu, 25 Jun 2009, Shelley Powers wrote:
> 
> No, I don't believe you're lying. But I can't helping thinking if we 
> were to look at this scenarios, we would find out you weren't as 
> vehemently against the decision, as you believe you are.

I'm not really sure how the degree of vehemence is relevant to anything, 
but ok. Generally speaking when one uses only reasoned arguments and 
research, the arguments aren't impassioned, so hopefully the degree of 
vehemence that I may or may not have felt would not be visible in the 
mailing list archives anyway.


> The same thing happened with the use cases, which you then used to 
> create the microdata section. You say most of the use cases weren't 
> good, we asked for examples of what makes a good use case, so that we 
> could create new use cases, accordingly, and you can't provide any.

A number of "good" sample use cases were described in that discussion.


> I don't think we're being unreasonable to ask what was your 
> justification for including some of the sections you did include.

I don't think you're being unreasonable either. As I've said many times, 
if anyone would like to volunteer to go through the archives and document 
how the draft spec came to be as it is, I would be very grateful and would 
be very happy to help. I personally do not believe I have the bandwidth to 
both document the work I've done as well as actually doing the work, at 
least beyond the documentation written by e-mail and sent to the mailing 
lists as the work is done. I wish that I did.


> It's just as fair as your continuing criticism and push back of 
> @summary.

I'm glad you agree that this criticism is indeed fair.


> >> Frankly, in my opinion, your sense of aesthetics shows in your 
> >> pushback against @summary. You specify it causes "harm", but nobody 
> >> has proved that it actually causes "harm".
> >
> > It has been shown that:
> >
> >  - in many cases where summary="" attributes are present on non-layout 
> >   tables, they have bogus values that are less useful to users of ATs 
> >   than no value at all. This harms AT users.
> 
> How? How are these "harming" the AT users? The tables were, themselves, 
> crap. They were layout tables. How, then, did the use of @summary 
> somehow make these inappropriately used html tables "harmful".

I am specifically only talking about non-layout tables here. Summaries on 
layout tables are apparently omitted from the output of ATs, and thus do 
not affect the user experience of AT users (though it could be argued that 
they take time from authors with nobody benefitting, and thus in some 
sense harm authors instead). Incidentally, I join Smylers in noting that 
if the algorithm used for categorising tables as layout tables could be 
documented, that would be of great help.


> More importantly, how many AT users have come forward and said, this 
> attribute is harming us?
> 
> One?

I'm aware of one user interview in which the user stated flat out that he 
ignored all summaries. I'm not aware of any AT users claiming that 
summary="" actually harms them in some way.


> >  - in the few cases where summary="" values are actually useful, they 
> >   would be useful to all users, not just AT users, but using 
> > summary=""   means the data is hidden from non-AT users. This harms 
> > non-AT users.
> >
> > The data for this has been repeatedly documented on this list.
> 
> Data where summary isn't used correctly, used on html tables, which were 
> themselves not being used correctly.

Certainly the bulk of summary="" attributes are on layout tables, but 
those are not relevant to this discussion given the aforementioned 
behaviour of ATs. It is the behaviour of summary="" on non-data tables 
that is more relevant. Data for this has been discussed before.


> But there's no proof of "harm". That's not an unfair request to make. 
> Where is the proof of harm?

As noted, the data demonstrating the two points I described has been 
repeatedly sent to the list, in a variety of different forms. The most 
recent, I believe, is:

   http://lists.w3.org/Archives/Public/public-html/2009Jun/0698.html

...which documents the sheer lack of useful values for summary="". Another 
example is:

   http://lists.w3.org/Archives/Public/public-html/2009Feb/0601.html

...which documents the second point I gave above (non-AT users being 
harmed by authors who intend to make their pages accessible).

If someone could describe the algorithm used by ATs to determine what is a 
layout table, we could perform more detailed studies focused exclusively 
on the summary="" values exposed to users, to see if, counter to all 
current indications, the summary="" values are actually helpful and not 
suitable for non-AT users. However, without a description of such an 
algorithm, performing such studies isn't practical.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'