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

On Tue, Jun 9, 2009 at 3:58 PM, <jgraham@opera.com> wrote:
> 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.
>

The point I keep trying to make is that all instances of "success" can
be determined by empirical observation. I used handicap parking slots
as an example of an implementation that would most likely be seen as a
failure, if we based the success of the implementation purely on
observations.

> 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.
>

I don't think there is one person concerned about summary that isn't
motivated by an interest in providing the optimum solution. Folks have
come up with alternatives, in the long term. The concern is what will
there be to use in the short term. The solution proposed with the
HTML5 specification--just plop it in with caption--does not address
the so-called problems that have been brought up with @summary.

If anything, it seems like nothing more than sweeping the whole
"problem" of accessibility under the carpet. Out of sight, out of
mind.

Pun definitely not intended.

> 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 think, again, you're making an assumption that the folks who are
concerned about @summary have dumped this attribute into HTML, and
then have been sitting on their hands ever since, toasting each
other's cleverness.

> 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.
>

I would think that @summary is better than nothing, and nothing is the
current approach in HTML5. Again, though, I'd rather have the
accessibility experts answer this question.

>> 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).
>

Keeping in mind, of course, that people are actually an element of all
these computational efforts.

> 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
>
>
>

What do you think of the summary element, as long term solution, that
Laura has pointed out to several folks? Other than she didn't use
bullets?

Shelley

Received on Tuesday, 9 June 2009 23:07:01 UTC