Re: Next steps for the ARIA syntax discussion

Henry,

I don't imagine that you have ever tried to drive software group enablement
for people with disabilities in a large corporation. These complexities
will result in push back by developers and the industry at large. Switching
back to a colon from a hyphen will not only delay us two years but I would
also interject that it will inhibit adoption.

While this should be a stump speech by Judy I will take the floor for a
minute and tell you that these problems pose an unnecessary barrier to
adoption and are not something the WAI would want. Yet, having spent so
much time and money in WAI I feel obliged to speak up. Deploying these
problems into a multi-billion dollar software business is not something IBM
wishes to deal with. While endless hours have been spent working this issue
out with browser manufacturers to get them on board, we have also spent an
equivalent number of hours getting application developers on board.
Overwhelmingly, developers gave a sigh of relief when we ditched the colon.
Aaron's examples are indicative of the frustration experienced by
developers.

Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             Aaron M                                                       
             Leventhal/Cambrid                                             
             ge/IBM@IBMUS                                               To 
             Sent by:                  ht@inf.ed.ac.uk (Henry S. Thompson) 
             w3c-wai-pf-reques                                          cc 
             t@w3.org                  Henri Sivonen <hsivonen@iki.fi>,    
                                       "public-html@w3.org"                
                                       <public-html@w3.org>,               
             05/24/2008 04:07          public-html-request@w3.org,         
             PM                        "public-xhtml2@w3.org"              
                                       <public-xhtml2@w3.org>,             
                                       w3c-wai-pf@w3.org,                  
                                       "wai-xtech@w3.org"                  
                                       <wai-xtech@w3.org>,                 
                                       "www-tag@w3.org" <www-tag@w3.org>   
                                                                   Subject 
                                       Re: Next steps for the ARIA syntax  
                                       discussion                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





ht@inf.ed.ac.uk (Henry S. Thompson) wrote on 05/23/2008 12:54:32 PM:
> >> > HST wrote:
> >> >> AML wrote:
> >> >> > I'm very concerned that there is not a realistic view about how
> >> >> > much this will hurt authors.
> >> >>
> >> >> I agree that if things were as bad as you thought they were, that
> >> >> would be a problem.  But I hope I've shown above that they are
_not_
> >> >> as bad as you thought.
> >> >
> >> > You don't think the fact that I got 2 different DOMs for the same
> >> > attribute in my XHTML is a problem? That happens when your
> >> > instructions are followed correct[ly]?
> >>
> >> Not a problem for most users, no, because as long as they stick to
> >> doing set/get/removeAttribute("aria:...") they will never notice that
> >> (in Firefox) the DOM sometimes starts out one way and changes to
> >> another.
> >
> > I want to ensure that everyone understands the proposal clearly:
> > HT is advocating that the DOM starts out one way and changes to
another,
> > for the same property value combination.
>
> Please be careful when you put words in my mouth. Not advocating,
> simply observing that this happens in some (quite limited, actually)
> circumstances.  The observed change happens _only_ if you introduce an
> aria: attribute into an XML DOM by parsing a document with such an
> attribute present, _remove_ the resulting attr node programmatically
> using removeAttribute, and then add it back using setAttribute.  This
> has got to be a pretty unusual sequence of events: by far the more
> common pattern is to use setAttribute only to change the value, and
> that does _not_ provoke the change we're talking about.

This admits the problem and dances around it at the same time. Let's be
clear: you are most certainly advocating for this proposal, and not just
observing where it would go wrong.

How unusual can the bug be if it happened in the very first example I
tried? Come on, you know that a checkbox is not unusual :) Before trying
it, I really wasn't sure how easy or hard the conversion to the fake
namespace proposal would actually be. The proposal made me believe that
mixing with real namespaces might actually go smoothly. Unfortunately it
just turned out to be a quagmire.

But, I'm actually glad the bugs in your proposal would happen in the most
basic of places! It's even worse when bugs are rare, because they sneak up
on you. The rarely seen bug is less likely to be accounted for ahead of
time and missed. Fortunately this bug would occur in the common checkbox.
But unfortunately it will still be missed because it does not produce
console or JS errors.

Bugs and complexities in the foundation of an architectural design will
ripple outward into the software ecosystem that is built on top. Setting a
property is at the very foundation of what makes ARIA work.

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.

- Aaron