Re: Stephen Ferg's Table Research

Hi Ian,

On Aug 14, 2007, at 2:42 AM, Ian Hickson wrote:

>
> On Tue, 14 Aug 2007, Jason White wrote:
>>
>> The assumption that most authors won't add markup to assist non- 
>> visual user
>> agents and assistive technologies is also not a good starting  
>> point from which
>> to discuss accessibility.
>
> (The following isn't intended to make any judgements on the various
> proposals for how to handle associating header cells with data  
> cells in
> tables. I'm just discussing language design at an abstract level  
> here.)
>
> There are two concerns with regard to specialised markup such as  
> markup
> intended for non-visual user agents. The first is that most authors  
> won't
> necessarily use the markup at all. That's not a huge problem,  
> though of
> course it is a disadvantage of such solutions and should be taken into
> account

Much of the discussion has moved away from requiring special things  
for non-visual user agents. While AT may benefit more from these  
solutions, most of these features we're discussing are proposed for  
support in all browsing UAs. So while it is a specialized markup,  
we're not talking about markup intended for only non-visual user  
agents. In terms of specialized markup, the same thing could be said  
of INPUT. Most authors won't necessarily use that element at all. I  
can't draw any conclusions from that fact about whether INPUT should  
be included in the language, and I don't think anyone else could  
either. Regardless, like INPUT these features are in the language for  
the authors that want to (sometimes need to) use them.

> (in particular, all other things being equal, if two solutions
> differ only in that one will get used by authors even when they don't
> think of users with unusual setups but the other won't, then the  
> former is
> likely better).

The former is likely better? How can you measure that. For example,  
HTML 4.01 included three solutions to the problem (each with slightly  
different solution niches: basic association, @scope association and  
@headers association). For each of the niches these solutions were  
designed for, one solution is better, in turn, than the others (in  
many cases the others wouldn't even work). For mildly complex tables,  
@headers is the best solution (the only solution). For simple tables  
with corner header cells, @scope is the better solution (though  
@headers would work). For the simplest of tables where the corner  
header cells are left blank the basic table algorithm is the best  
solution (though @scope and @headers could be used instead).

> The second is that authors will misuse the markup. This is a much,  
> much
> larger, and very real, problem. If markup is misused more than it  
> is used
> correctly, especially if the misuse is indistinguishable from  
> correct use
> from a computer's point of view, then the feature can in fact end up
> making the user experience _worse_ for users in ususual configurations
> than the absense of any feature at all.

I would agree with that. However, the issue for us spec writers, is  
what should be done about that? Should the features be dropped? Is it  
a feature best handled by authoring tools (too complicated for casual  
hand-coding)? Are there more clarifying prose we can provide in the  
new recommendation? Dropping those features is only one of many  
solutions. I look forward to when you get up to speed on the wiki and  
you're ready to begin discussing solutions.

> An example of this would be the usemap="" attribute on <input>  
> elements. I
> recently decided to not supports this attribute on <input> elements in
> HTML5, after having done a thorough study which discovered that in  
> almost
> all cases, pages that used the usemap="" attribute on <input> elements
> actually behaved better in user agents that did not support that  
> attribute
> than in user agents that _did_ support it. [1]

I hadn't seen the discussion of this and didn't see anything about  
this on the wiki. Its hard to discuss this issue without more  
background, but where could you have found consensus for a change  
like this? Like I said I don't even remember this topic over any of  
the channels, and I've been following them closely.

Again, there are multiple solutions to such a problem. It would be  
interesting to know what UA misbehavior you encountered. Could we  
provide clarifying language to guide UAs. Could we file bugs with  
those UAs. Dropping client-side image maps for forms in a  
recommendation that is focussed on web applications seems completely  
counter-intuitive to me.

> It's sadly the case that most features that don't have an effect in  
> the
> most common configuration (the configuration most often tested by  
> authors)
> end up abused like this, which is a very strong reason to avoid  
> this kind
> of feature when designing the language.

This is why the thrust of many threads in the WG have leaned towards  
making the features universally applicable to all browsing UAs.

> Having said that, it's not always bad. The alt="" attribute, for  
> instance,
> is used widely, and is used correctly in a significant fraction of  
> cases.
> That's why we have to examine each case individually, and is why  
> research
> into how features are actually used is so important.
>
>
> -- Footnotes --
> [1] This was a thread in which I was dealing with feedback sent to the
> WHATWG list some time ago. The e-mail in which I detail the study  
> is here:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-August/ 
> 012334.html
>

With all the calls for research on the list, I'm surprised such an  
unscientific statistical analysis would be sufficient to drop client- 
side image-map support for forms. I think changes to the draft should  
be guided by consensus informed by more rigorous research methods.

Or s this just a change you're proposing. Will it be added to the  
wiki too?

Take care,
Rob

Received on Tuesday, 14 August 2007 08:52:54 UTC