- From: John Foliot <jfoliot@stanford.edu>
- Date: Thu, 1 Apr 2010 17:31:32 -0700 (PDT)
- To: "'Shelley Powers'" <shelley.just@gmail.com>
- Cc: "'Steven Faulkner'" <faulkner.steve@gmail.com>, "'Jonas Sicking'" <jonas@sicking.cc>, "'HTMLWG WG'" <public-html@w3.org>
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