Re: ISSUE-96 Change Proposal

On Thu, Apr 1, 2010 at 2:14 PM, John Foliot <jfoliot@stanford.edu> wrote:
> 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.

John, CSS is nothing more than a "bolt-on" for style. RDFa and
Microformats are a "bolt-on" for semantics. JavaScript is a "bolt-on"
for behavior, come to that.

What you call "bolt-on" most developers call extensibility and re-usability.

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

The hidden attribute requires the exact same lines of javascript as
using aria-hidden. Why is better because it's built into HTML? It's
actually worse, because turning off JS doesn't turn off the hidden
attribute. Loss of control for the user.

Same for details -- no way to turn it off _except_ use JS. No way for
the user to turn it off by default.

As for size, most of the photos I display at my sites are larger than
any JS I would use. Combined. The size thing doesn't really compute,
particularly because something like the progress element still needs
JS, and the amount of code to create a progress bar is so small.
Seriously, even with providing more options and functionality than are
available with the progress element, the jQuery UI progress bar, WITH
ARIA, is less than 50 lines of code. Now, minified, how big do
_really_ think that file will be?

Lines of code? I can implement a widget comparable to details element
in about ten lines of code, total.

Everything you're saying applied _ten years ago_. In the last decade
we've made extraordinary leaps in applications using a variety of
technologies, not just HTML. Or not only HTML.

It's almost as if the decade that's past since HTML 4.01 was released
and now is lost. All the innovations, all the advances made in
ECMAScript, in CSS, in SVG, canvas... Is all of this a bridge, because
it's not codified in HTML?

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

Any processing, whether built into the browser or based in JS, will
require CPU. Most of the CPU is taken up with processing the visual
display, regardless of what triggered the action to change the visual
display.


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

But it will never be built in. You all seem to assume that really,
there's only 20 or 30 built-in behaviors and once we have these, the
job is done.

This will never happen. The web is synonymous with innovation.

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

You know it's odd, but in all of the ARIA stuff I've read online,
tutorials, articles, and specs, I've never read anyone who wrote,
"This stuff is fun!"

When you coach things as a "serious duty", don't be surprised if the
reaction is equivalent to telling a 6 year old to eat his broccoli,
because it's good for him.

You can ask Kathy Sierra and Molly if I'm right on this.

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

Appreciated. I hope I don't seem overly aggressive. I should stop,
pull back, and take this up on my weblog.

> JF
>
>

Shelley


Shelley
>
>

Received on Thursday, 1 April 2010 20:37:57 UTC