- From: James Graham <jg307@cam.ac.uk>
- Date: Sat, 16 Feb 2008 00:47:13 +0000
- To: Karl Groves <karl.groves@ssbbartgroup.com>
- CC: HTML Issue Tracking WG <public-html@w3.org>
Karl Groves wrote: > Naturally, the context we're applying these checks are geared toward finding accessibility issues, but it illustrates the point that if we were to guide our decisions of whether to keep/ delete an element or attribute solely on what web authors are doing, we'd be taking the wrong approach which may also have negative effects upon some specific populations of users. > Indeed, we do not want to make changes which make an overall negative impact. However knowing exactly which changes will have a detrimental effect is not always a-priori obvious, and, in particular, cannot be determined merely from looking at the stated goal of the feature being considered. Consider the examples discussed in [1]. These are all laws which were designed to help some specific population, but have had some unexpected negative consequences for the very people they were supposed to aid. This illustrates the fact that, even when solutions to problems are designed by the leading experts with the best intentions, there needs to be a feedback loop to ensure that the original problem actually gets solved. Specifically the feedback too has to look like: 1) Design and implement the best solution you can 2) Assess the impact that your solution actually has on the problem you were trying to solve through observations/experiment 3) Go to step 1) taking into account what you have learned Without steps 2) and 3) it is unlikely that you will ever make any progress in addressing the issue you originally cared about. For developing HTML analysis of existing usage is an essential component of step 2). > I agree with you that "An element that is never used in the correct way has no value to the user", but I disagree that this should necessitate modifying the spec to merely do away with items which have real value. Improper markup is the developer's fault, not HTML's. At some point, the developer needs to take responsibility for his own shortcomings. > Assigning blame isn't really very interesting unless you are a lawyer looking for someone to sue. Nor is it often very helpful; in each of the examples in the article one can find a group other than the lawmakers to blame for the unintended consequences. However in each case that group is acting in it's own economic self interest something which it's generally very difficult to prevent people from doing on a large scale. Merely suggesting that they take responsibility is unlikely to be successful in effecting change. Applying the feedback loop above to the underlying problem and existing solutions is much more likely to work and actually address the issues. In the case of HTML accessibility problems, one of the ways to do that is to look at what people are already doing and see how we can design features to work with that (this has been done somewhat with table headers, for example). Another way is to look at where people aren't using existing mechanisms to try and work out why. This requires people to actively investigate how markup is being used and to be open minded enough to accept that there may be a disconnect between the stated purpose of something and the effect that it actually has in practice. [1] http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=1358485200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all&oref=slogin
Received on Saturday, 16 February 2008 00:47:29 UTC