RE: ISSUE-96 Change Proposal

Shelley Powers wrote:
>
> >> What you call "bolt-on" most developers call extensibility and re-
> >> usability.
> >
> > Accessibility cannot be 'extensible' in the same way that style,
> enhanced
> > semantics and even 'functionality' can be extensible.
> >
> 
> Extensibility is a purely technical concept -- it has nothing to do
> with whether something is good, or something should be required. It
> just means that you can incorporate new uses without having to back to
> a standards board.

Then what I meant by bolt-on earlier is not extensibility, it is bolt-on.
You must *add* ARIA to elements to achieve accessibility today, it is not
'accessibility' made natively available. 

> 
> Does the accessibility community really want to have to back to a
> standards board in order to ensure a new innovation is accessible?

No, but if a new solution is to be codified into a spec, then it should
have accessibility baked into it, not as something additional that can be
(but might not be) added to it - I (we?) want accessibility to be the egg
in the cake, not the icing. 

ARIA is simply the band-aid that we have today, but it is far from perfect
because it requires extra effort on the part of the author. We have a hard
enough time getting them to add appropriate @alt (even today), and hoping
and praying that moving forward all content authors and developers will
embrace ARIA with gusto is unrealistic. But if we give them something, and
suggest that by using the proper tool for the job, that accessibility
comes instantly, with zero extra effort, then we are likely to see
increased take-up, and accessibility wins.


> 
> The very nature of ARIA demonstrates this. You can use it now, you
> don't have to wait for new elements from HTML5. Eventually, some day
> in the future, if you count on building objects into versions of HTML,
> HTML will be a wall, not a door.

I agree, and I am not advocating abandoning ARIA, but when you knock that
hole in your wall, it is important from the get-go to ensure that people
know it is a window or a door, and not presume that later people will go
head and specify it. We have specific definitions for doors and windows,
even though both are holes in walls: are you saying that <hole_in_wall
role="window"> makes more sense than <window>? 

When you knock that first experimental hole through, using an ARIA like
construct helps define what the hole is for; but eventually it is simpler,
faster and easier to simply refer to it as a window, rather than a hole in
the wall that is a window. <hole_in_wall role="window"> would work in the
early days, but when it came time to review and update the building code,
it would be much better to actually call the thing a window, rather than
perpetuate that every time you knock a hole in a wall you need to identify
_what it is for_ by using *additional* code.

> 
> But it can be fun, too. We can do the right thing, and have fun, too.
> 
> I giggled like a mad woman when I added ARIA to an example for my
> book, and it actually worked with NVDA. I called my roommate in to
> show him. I had a blast. Was that somehow wrong?
> 
> When I wrote about it in my book, I wrote about how much fun I had
> working with the ARIA states and roles, and especially live regions.
> Was that somehow wrong? Not striking a serious enough tone?

Not at all, and I am personally glad that you had fun. (Yes, doing the
right thing can also be fun!) But consider, if new HTML5 elements added
accessibility value with zero additional input from the author, wouldn't
that be fun too? ("Check it out, one new element, and it is instantly
accessible too - sweet!")

> 
> Actually, no, I'm saying we should tell developers a) how simple it
> is, b) that it works, and c) that it can be fun to do the right thing.

The very same could be said about using some of the new elements as well;
again, the new elements also can be appreciated by a wider cross-section
of the user-base - it's not *just* for accessibility. Just look at all the
twitter traffic out there from devs trying out HTML5 for the first time...
(that I wish the same kind of excitement could be generated for trying and
using ARIA)

Simple is fun too, and I suspect that developers looking for "fun" in
HTML5 will likely gravitate towards some of the newer stuff, before
learning how to work with ARIA (which has been evolving for years now).

> 
> Ten years ago, five years ago, even a couple of years ago, we did not
> have this capability. We developers were frustrated because we were
> told to create accessible applications, but we didn't have the tools.
> Now we have the tools.

ARIA is but one tool, and one that you need to get out of the tool-box and
apply after the fact to "fix" stuff that is not natively accessible.
Learning how to use ARIA can be fun, but continually having to use it (at
the local developer level) will likely result in a drop-off after early
'play', and/or somebody will eventually come along and say, "...wish we
could do the same thing without having to use ARIA" (wanna bet?)

The single largest win we have today with ARIA is that it *is* being baked
into script libraries. But a quick review of the numerous jQuery UI
plug-ins confirms that even there, not all plug-ins are created equal (and
as a matter of fact, I suggested to someone close to that project not too
long ago that the jQuery plugins 'store' could benefit by indicating which
plug-ins include ARIA support versus those that don't - the suggestion was
well received and so fingers crossed).

Cheers!

JF

Received on Friday, 2 April 2010 00:32:06 UTC