RE: ISSUE-96 Change Proposal

Shelley Powers wrote:
> 
> I have to ask: what is wrong with ARIA?
> 

There is nothing *wrong* with ARIA, but from the get-go ARIA has always
been considered a bridging solution, as it essentially perpetuates the
"bolt-on" philosophy of Accessibility on the web. ARIA was designed to be
a retrofitting solution (for HTML4/XHTML1 & what was first called DHTML),
and not necessarily the best path forward; I suspect in that regard most
accessibility specialists will concur.

As well, ARIA is implemented as an attribute mechanism, whilst these new
elements, are, well, elements.  There is a philosophical discussion on
whether elements are better than attributes, but many seem to agree that
elements are more 'powerful' than attributes:

 * Elements are better than attributes for semantics, javascript, css.
 * If something needs to be referenced you should normally make it an
element, with an id attribute. 
 * If something represents a separate entity, make it an element: you
might want to add attributes later.

Shelley also wrote:
> 
> I've been developing for the web, and writing about web development
> for 15 years. Here's what I know about developers: folks are still
> going to use these libraries. They're not going to stop using them,
> just because HTML5 is now a competitor for their favorite libraries.
> If what you give them isn't better, _they won't use it_.

So then, it seems that the reason why having an element over an ARIA
attribute, or for why pushing behavior to the UA instead of scripting it,
is unclear; why is it _better_(?).

Here's a few reasons (to my mind):

1) having a simple element express something instead of requiring a bunch
of lines of scripting is way more efficient. It is simpler to author,
simpler to implement and produces cleaner and lighter code. (In the day of
minification of every line of code, be it JS or HTML, there is a clear
desire and demonstrable need for as light a code packet as possible. Tools
like YSlow are constantly suggesting to trim down scripts and CSS that is
not being used)

2) there is a cost to using JavaScript. It is a given that for modern web
app development, client side scripting is a necessity. But client side
scripting has a cost, and on the mobile platform in particular, that cost
is battery life, as your un-tethered device needs power for the CPU it
takes to process the script. So moving functionality into the browser
natively, instead of relying on scripting which requires additional CPU is
an efficient design choice w.r.t. power usage. 

3) referring back to the beginning of this note: Having 'accessibility'
built-in rather than bolt-on (which is what ARIA is) is a fundamental
desire of most of us in the a11y community. We've often differed on how to
achieve that goal, but the bottom line desire of that sentiment is shared
by both the WHAT WG/HTML5 WG and the a11y folks.


> Instead of downplaying ARIA, and joining with the W3C and the WhatWG
> to package these "common" widgets into the HTML markup, we should be
> continuing the momentum that we're seeing this year, and get web
> developers to embrace ARIA. Now is the time, there's no better.

And subsequently:
> Now, in defense of the developer and designer, we haven't been
> building accessibility into many of our applications in the past,
> because we didn't have the capability. Now, we do. Now comes the
> challenging part -- changing attitudes, and educating the ignorance.
> 
> We'll need this no matter what, because you can't depend on building
> everything we need into HTML. I can't even imagine why the WAI group
> thought this was possible.

I've often expressed the difference between Universal Design and/versus
Accommodation.  There will always be a need for both, but if we can get
Universal Design to minimize the additional requirement of Accommodation,
then we are headed in the right direction.  Packaging common widgets into
the User Agents (expressed through dedicated markup constructs) is
actually the bigger win, as it is a Universal Design decision: the
developer/designer doesn't have to "build accessibility" into anything -
it just happens when you use the right tool.

Shelley, those of us who have been doing web accessibility for any length
of time have spent close to 80% of that time trying to "change attitudes,
and educating to the ignorance". But that alone ain't gonna cut it (just
ask @longdesc) - it also needs to be simple, efficient, and natural - not
something that needs to be 'added' to the mix, but something that is
intrinsic to that mix. The WAI group "...thinks this is possible" because,
frankly, we've been discussing it for over a decade now, long before
others even understood what we were talking about, and we know what we
know because we've learned it the hard way.

If I had 2 minutes to sell Universal Design or Accommodation, you'd get
*3* minutes of Universal Design preaching from me.

Just my $0.02

JF

Received on Thursday, 1 April 2010 20:14:40 UTC