Strategic decision time (was Re: Next steps for the ARIA syntax discussion)

Hash: SHA1

Aaron M Leventhal writes:

> I think W3C really needs to figure out what is in its DNA at this point. 
> Contributors that want credibility need to provide implementors with 
> proposals that will actually work, not theories that will break the web as 
> it exists today. We're spending too much time debugging proposals asking 
> us to change what already works.
> While I realize it's not the way people do things around here, I think it 
> would be leadership by example to just withdraw this proposal because of 
> the proven bugs. Let's not try to whitewash problems and pretend they 
> don't matter because they're rare. Admittedly, I have often made mistakes 
> in my own proposals. I promise to do by best to keep them clear of obvious 
> problems before recommending them. I will listen to the community and try 
> to keep the path clear so everyone can keep improving the web through 
> standards.

I understand, I think, the depth of commitment and the extent of the
work that has been done already to get ARIA accepted and implemented,
and I hear that you are very keen to have the W3C endorse your
efforts, publish the spec. and concentrate on promoting uptake.

I have never said that the aria: approach was without problems.  My
efforts throughout this discussion have been directed at accurately
identifying the costs of _both_ approaches, so that a thoughtful and
well-informed decision can be made based on the agreed facts.  You
have identified a problem that I missed, and that's a good thing,
because it adds to the facts we have in front of us.  But it doesn't
necessarily determine the decision.

We have to set against the problems with aria: the medium- and
long-term negative aspects of the aria- approach, which focusses on
ease of ARIA integration in text/html environments at the expense of
costly integration throughout the application/...+xml universe.  From
my perspective, the cost of aria: in the text/html environment is
modest, manageable, and declining over time, whereas the cost of aria-
in the application/...+xml universe is large and permanent.

The reality as I see it is that ARIA integration into the text/html
world is going to be messy and bug-prone in the short term no matter
what we do.  If you contrast the simplicity of either your or my
simple checkbox example [1] [2], which only works in some browsers,
with the complexity of the genuinely interoperable versions [3] [4],
the familiar pattern of non-obvious cleverness which is the reality of
fully interoperable Web 2.0 Javascript is evident.

Of course it's a judgement call, but giving DOM consistency a veto
seems to me an over-reaction, when doing so isn't even sufficient to
give us interoperable solutions.

So, I end up still weighing the long-term value for the whole W3C
community of a clean extensibility story, with the specific benefit
for ARIA of _not_ requiring detailed bilateral negotiation with every
WG that owns an XML language into which ARIA should integrate, more
highly that the marginal cost of aria: vs. aria- to text/html script


- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail:
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Thursday, 29 May 2008 12:26:52 UTC