RE: ARIA as stop-gap (was Re: Next steps for the ARIA syntax discussion)

I'm currently collecting alternative names for ARIA along with their
authors.

 

1)  "Band Aid" (TV Raman)

2)  "Stop-Gap" (Steven Pemberton)

3)  ...

 

If anyone knows another one, I'll be lucky of knowing that. 

 

In my personal opinion, ARIA is a blessing, addressing the unsatisfying
current situation, and even better: it simply works. NOW.

 

-       Stefan

 

 

Dr. Stefan Schnabel 
Accessibility Expert 
User Experience - Accessibility 

SAP AG
Dietmar-Hopp-Allee 16, 

69190 Walldorf, Germany


T: +49 (6227) 7-65652
F: +49 (6227) 78-29877


mailto:stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com>  

 

 

 

From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Aaron M Leventhal
Sent: Mittwoch, 28. Mai 2008 16:34
To: Steven Pemberton
Cc: L. David Baron; public-html@w3.org; public-xhtml2@w3.org;
wai-xtech@w3.org; wai-xtech-request@w3.org; www-tag@w3.org
Subject: Re: ARIA as stop-gap (was Re: Next steps for the ARIA syntax
discussion)

 



"Steven Pemberton" <steven.pemberton@cwi.nl> wrote on 05/28/2008
03:23:33 PM:
> Let me just say upfront that I think ARIA is needed, and will be
needed  
> for some time yet. But let me also answer your question about why we  
> should strive for it to be a stop-gap in the long term in order to get

> even better accessibility. 

We definitely agree about striving for it to be stop gap. The less ARIA
is needed the better. But I'm extremely skeptical about getting there
based on what I see today. Realistically, to get beyond the need for
ARIA will require many things, such as: 
1. Getting the major vendors to agree to support this next great thing 
2. Agree to the details 
3. Get browser vendors to implement it in a compatible way 
4. Get users to update to new browsers so authors can use the new
standards 

ARIA got around this adoption problem by implementing in 1 key chain of
technology along the way (Dojo -> Mozilla -> ATs) and trying to help
anyone that wanted to join the work. The key was that current web pages
still work in legacy browsers even when ARIA is not supported -- they
just won't be accessible. But then, JS widgets aren't accessible to
start with so nothing lost. Having one major working implementation,
with docs, was a great way to encourage the larger community to adopt
and implement. 

Without getting into the details of XForms, or XBL, or whatever, getting
traction for any of those things will be very, very difficult. How are
you actually going to get websites to move to these great new things if
it will break web pages on current browsers? These things don't even
gracefully degrade. No one wants to write 2 web sites. 

If the strategy to get browser & author adoption is just technological
elegance, you'll never get off the ground. Authors won't write to it
without browser support and some browser will always lag behind unless
they're forced into supporting its used in important places. Typical
chicken & egg. 

Again ARIA didn't have this problem because it can just be added to
current websites without breaking them. We could just start implementing
it without breaking working stuff. 

Almost everyone has worked hard on stuff that didn't live up to
potential because the adoption strategy was broken. The failure pattern
is way too predictable, and it's painful to watch. 

So in the end I agree we should strive toward removing the need for
ARIA. I would love to hear any proposal that includes a solid adoption
strategy that doesn't require luck and good faith in all vendors caring
about the web. We're probably just dreaming now, and I don't see the
point. 

- Aaron