what issue gets veto? [was: Re: Strategic decision time (was Re: Next steps for the ARIA syntax discussion)]

On 29 May 2008, at 8:13 AM, Henry S. Thompson wrote:

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

Yes, I agree that "Web Application programming is not for the faint
of heart."

On the other hand, we regard the unnecessary problems that 'aria:'
would introduce to be an unnecessary straw to lay on the camel's
back.  We are already seriously at risk that what we ask application  
authors
to do is too complex for them to learn before they abandon the attempt.

'aria:' threatens to push this over the brink to where the application
author public opinion congeals around 'unworkable' and we are dead.

There is a difference between there being wrong things a programmer
can do, and building bugs into the infrastructure that they have to
decipher and work around.  Let's not go to the latter?

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

Consistency in the DOM programming platform across host languages is
very important for compound documents and the emergency of a
multilingual Web.  This gets a vote, but not a veto.

But consistency in the state-machine behavior of a widget state
is a make-or-break requirement; something we have to deliver or
not bother trying.  In this sense, the coherence of the DOM
programming interface does have a veto for WAI-ARIA.  If we can't
win usage by Web Application authors writing CSS+Script+[X]HTML
applications, we shouldn't bother.

It is a question of what sort of consistency that you are talking about.

If it's the idea that the same script works in HTML and XHTML, then
the costs and benefits derive in the timeframe and to the extent that
application authors and sites take up XHTML.  This is a long-term
migration issue and the benefits accrue to the consistent version,
not to 'aria:' .

But if it's the kind of inconsistency that Aaron stumbled upon, where
the behavior is different depending on whether you set the state
from the hypertext or the DOM method -- that's an intolerable
failure of determinism in a programming platform.  We can't expect
application developers to accept that.  No amount of future gold
at the end of the rainbow should lure us down that path.

http://lists.w3.org/Archives/Public/www-tag/2008May/0202.html

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

Henry, with all due respect, you don't understand the appropriate
costs and benefits.

The costs of not using "Namespaces in XML" directly for insertion
into host languages start with the first language after HTML, XHTML,  
SVG.

The cost of reverting to the colon at this time would be at least a
year in schedule creep.  It is the accessibility community and the
application writing community who have the costs and benefits.  And
IMHO for both of these, we should drop all host languages beyond HTML if
that was what it took to recover that year's slip.  We haven't done
that, no matter what it may seem.

The cost of waiving automatic insertion in XML formats beyond SVG is
imperceptibly small, in the WAI-ARIA-appropriate cost metric.

http://lists.w3.org/Archives/Public/www-tag/2008May/0185.html

Having to create a separate insertion strategy for minority languages
is a preferable cost to throwing the ARIA train off the rails at
this point, which 'aria:' would do.  And we don't even have to go
there.

Thanks to your probing, we have learned that

(a) most of the native attributes of XHMTL and SVG are in no
namespace (per the Namespaces Rec) anyway.

(b) no-namespace attributes and Namespaces play fine together.

.. so yes, we are considering rolling back to defining _in our  
specification_
only the no-namespace insertion _in our specification_, *without
preventing* other, later experiments in borrowing the vocabulary,
using other techniques.

Al

> ht
>
> [1] http://www.mozilla.org/access/dhtml/checkbox-colons.xhtml
> [2] http://www.w3.org/XML/2008/04/ARIA-Testing/leventhal-colon- 
> xhtml.html
> [3] http://test.cita.uiuc.edu/aria/checkbox/checkbox1.php
> [4] http://www.w3.org/XML/2008/04/ARIA-Testing/uct-colon-xhtml.html
> - --
>  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: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is  
> forged spam]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFIPp33kjnJixAXWBoRAmOQAJoD2N/vBaPhVRjlQ9NigQ0QwI0rpgCfUD2o
> HQz2RtOwO1uo9cPQHFwWPqY=
> =JEHT
> -----END PGP SIGNATURE-----
>

Received on Thursday, 29 May 2008 18:41:26 UTC