Re: ISSUE-96 Change Proposal

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

When you use the word "band-aid" I immediately turn off on the technology.

Band-aids is what we have to use to make sure event listening with IE.
Band-aids is what we have to use to display a page as XHTML for most
browsers, and HTML for another. It's a workaround, a kludge.

I'll make effort for something that's real. I resent the time I have
to spend on something that is nothing more than a kludge.

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

No. It's not "new* to web developers. Color picker is built in. Big
whoop, I can point out a color picker made with SVG from early in the
2000's, 2004 I think. It's actually quite old technology. And doesn't
really compare with what's available in many libraries.

Since I'm using one of the libraries anyway (jQuery), I'll just stick with it.

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

But how long has ARIA been real? The spec isn't event a candidate
recommendation yet. Support for it is very new, I know what it was
only added to SVG tiny in 2008 or so.

People are definitely not going to be willing to put time into
something that's only a bridge, a kludge.

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

I mentioned the word fun, I didn't use the word play. I also find
working with Drupal to be fun, too. But it's not _play_ when I do so.

People haven't stopped using CSS, though using tables for layout was
much easier. That requires a significant investment in time, too.

And when you build something into a library, they don't have to apply
it themselves. It is being incorporated into jQuery. That means
everyone who is using jQuery and jQuery UI is using ARIA.


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

I imagine that's why the AOL company is providing funding to complete
the integration of ARIA into jQuery.

Obviously we disagree. Be comforted in knowing that no one agrees with
me, and everyone agrees with you.

I recommend that you write a counter-proposal for Proposal 96.

> Cheers!
>
> JF
>

Shelley

Received on Friday, 2 April 2010 01:12:32 UTC