Re: Summary of Thursday's IRC conversation about @summary

Quoting Shelley Powers <shelleyp@burningbird.net>:
>
> You keep using one metric, an arbitrary count, as your measurement of
> success, Henri. And I keep repeating that, especially when it comes to
> issues of accessibility, that counts and empirical observations are not
> the most effective determinant of what counts as success.
>
> Sometimes a measurement of success is for those who need such features
> to be assured that they are not forgotten; nor that those who would
> create a new generation of web pages discount their challenges by
> removing the few features created specifically for them.
>
> How people perceive the actions of the HTML WG become just as much a
> metric for success when it comes to meeting needs and demands for
> accessibility.

The notion that the success of a feature should be determined not by
whether it actually successfully addresses the use cases that have
been set out for it but instead by whether it creates a perception of
good intentions seems to me to be very dispiriting. We are surely
obliged to make HTML as useful to all users as we can not just to do
the things that give an appearance of being helpful.

This is particularly true in an area like accessibility where it is
reasonably easy to come up with features that look like they should
work but much harder to actually make solutions that really work well
in the hostile environment of the web.  Indeed it seems patronising
to users to expect them to accept less than the best solutions that we
can offer under the assumption that they will be more grateful for
things that are obviously designed for their situation yet relatively
ineffective, than they will for an empirically better, but more
subtly constructed, approach.

If we are serious about providing the best solutions we can, research
into existing practice is a necessary component of determining what
the best solution actually is. Developing a high quality markup
language, like many other problems, can be effectively tackled by
using an iterative approach - something gets proposed to solve a
problem, experiments are done to see how well the problem is solved,
based on the results of the experiments a refinement to the solution
is considered. That's basically how all of science works (except with
"explanation of a natural phenomenon" in place of "solution to a
problem") and it has been a rather successful method. I think we would
be foolish to assume that we can forgo this feedback loop and yet
produce optimal results.

I stress that the above is all independent of whether the summary
attribute is actually the best solution to the problem it attempts to
address. If it is then we should of course keep it. If not then we
should not.

> Regardless, I will repeat: the sole purpose behind removing @summary
> seems to be that it will be "harmful".

I think that is not quite the right way to look at the situation. A
better approximation to the right question is "is the opportunity cost
of @summary low enough that we should have it in the language?". Of
course this is not quite right because the various possibilities are
not, strictly speaking, mutually exclusive; that is, there is the
possibility of having more than one way to provide equivalent
functionality. However that too has a cost in terms of the increased
difficulty of learning the language, the more complex specification,
the possibility of mixed advice to authors, more complex
implementations, etc. In any case, the point is that @summary does not
have to be, on its own, actively harmful for leaving it out of HTML 5
to make sense; it just has to have lower value than some alternative
solution to the same problem that including it excludes.

These calculations are, of course, rather non-trivial to do since it
is difficult to quantify the value of various solutions. Hence
language design is part science (getting all the data that you can to
make the most informed decision possible) and part art (making
judgment calls about which decision is, in the final reckoning, best).

In the case of @summary my personal interpretation of the situation is;

1. It is generally little used

2. It is not effectively solving the use case that it is supposed to
address (that is, authors are generally not using it to provide longer table
summaries that detail the layout of the table for the specific benefit
of the visually disabled)

3.  It is sometimes used to provide information that is helpful to AT
users. Often this information would also be helpful to other users, if
it was available to them.

4. It is designed in a way that we would not seriously consider if we
were starting from a blank slate today. In particular the reliance on
hidden data is generally considered an anti-pattern, media-specific
markup is generally considered an anti-pattern (especially in cases
where the media-specificity means that most authors will not have
access to the data) and placing content in attribute values is
generally considered an anti-pattern (today no-one would design <img>
as an empty element)

None of this proves that the attribute is harmful. However points 1 and
2 do suggest that, @summary is providing relatively little value
today. Point 4 indicates that we ought to be able to do better taking
into account everything we have learnt about designing markup
languages for the web. Thus I conclude that continuing to promote
@summary as a solution to accessible table descriptions is unlikely to
be the best decision and we would be better off designing a new
solution and promoting that instead. I have already suggested one
possible solution that I believe accounts for all the use cases so far
raised [1].

[1] http://lists.w3.org/Archives/Public/public-html/2009Jun/0283.html

Received on Tuesday, 9 June 2009 20:59:21 UTC