- From: <jgraham@opera.com>
- Date: Tue, 09 Jun 2009 20:58:29 +0000
- To: Shelley Powers <shelleyp@burningbird.net>
- Cc: Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org WG" <public-html@w3.org>
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