W3C home > Mailing lists > Public > public-html@w3.org > February 2008

Re: ISSUE-34 (commonality): Can we get access to tools that determine how often markup is used on the web?

From: James Graham <jg307@cam.ac.uk>
Date: Sat, 16 Feb 2008 00:47:13 +0000
Message-ID: <47B63291.1020309@cam.ac.uk>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:52 UTC