Re: ISSUE-96 Change Proposal

Wow, sorry for all the typos in my emails.

I think you get the drift, though.

Shelley


On Thu, Apr 1, 2010 at 7:12 PM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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:18:58 UTC