Yesterday there was some noise surrounding HTML5 and the myth of WAI-ARIA redundance. It surprises me how quickly finding the actual problem here is dismissed as “who knows.” It almost seems as if some part of the accessibility community has shifted from promoting the writing of clean markup, to promoting write whatever the fuck you want as long as you make it accessible. Write whatever the fuck you want with some WAI-ARIA sugar on top is in some scenarios the only thing what works right now. I do not believe that means we should just let it run its course. The real solution to making a button implemented using five div elements and some scripting accessible is not WAI-ARIA. It is to drastically improve the styling capabilities of <input type="button">.
The solution to making new patterns accessible is to create smarter ways for people to do them that are automatically accessible and do not require annotation with WAI-ARIA. WAI-ARIA is still useful to push the envelope, but the long tail of the Web is just not going to care enough. It would be terrible if only the top five hundred or so websites in each country were accessible mostly due to accessibility advocacy groups. Especially since we have the ability to do much better than that.
As an example take the new HTML5 progress element. It greatly simplifies creating a progress bar and when implemented correctly in user agents it is automatically accessible. However, the whole user interface part of the element is somewhat up in the air. I do not think I am personally the right person to work on that, but that is the kind of problem we should be trying to tackle.
(See also HTML5 Forms and styling of form controls on www-style.)
It almost seems as if some part of the accessibility community has shifted from promoting the writing of clean markup, to promoting write whatever the fuck you want as long as you make it accessible.
This statement is both inflammatory and untrue.
Unfortunate but true: Clean markup that does not convey the required sematnic information is meaningless, dirty markup that does is not.
The accessibility community has and continues to advocate the use of native features where implemented accessibly, but we are also realistic that despite this developers will continue to write what they want. Furthermore none of the native features of HTML5 that support accessibility are as yet implemented accessibly in any browser, so what are we supposed to be promoting? If developers choose to write crap code but need to make it accessible, then yes the promotion of the ARIA is the right thing to do.
Also you appeared to have skimmed over the issue that their are many features available in WAI-ARIA that are not in HTML5.
does steve advocate using shit markup sprinkled with WAI-ARIA? no. does google apparently like to use shit markup instead of proper elements like button? yes, and they have for quite some time...for instance google maps has had that problem for a long time as well - see for instance my dev.opera keyboard-accessible google maps article to show the burning hoops accessibility-minded devs have to jump through just to get their stuff to be usable. as they seem to have ignored pleas from the accessibility community to use correct markup for whatever reason, steve's assertion is that at least if they're unwilling to change their ways, pretty please at least add some WAI-ARIA to your markup monstrosities...
yes Anne, suggest you go back and re-read that article. Seems the only person who is advocating status quo for ARIA is *not* a person from the accessibility community, but rather someone who recently discovered ARIA and giggled like a mad-woman.
Those who have been doing this for long enough know that ARIA is a bridging solution, but a long term investment too. We want and promote ARIA, as for one it allows devs to continue to be creative, but at the same time, as even the ARIA Draft Spec states:
WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. This is important because the invention of new types of objects is faster than standardized support for them appears in page languages.
It is not appropriate to create objects with style and script when the page language does provide semantics for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively.
It is expected that, over time, host languages will evolve to provide semantics for objects that previously could only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature. Legacy content may continue to use WAI-ARIA, however, so the need for user agents to support WAI-ARIA remains.http://www.w3.org/TR/wai-aria/introduction#co-evolution
In this regard, I do not think you will find any divergence of opinion from the majority of the accessibility community. Please try to be factual in your observations.
Anne, you misread what Steve wrote. He's not advocating doing what Google does. But Google will do what Google wants to do, same as many other developers. At least ARIA provides a way to ensure it's accessible.
The issue with the progress element is not about accessibility, but about ignoring the state of the art that exists today. And ignoring what developers will do.
The progress element in HTML5 is primitive, unimplemented, can't be customized, and can't be styled. It's six years too late to be useful.
The state of the art today is customizable, extensible, stylable, lightweight, and _well designed_ widgets that we can incorporate easily into our sites, in most cases using the same JS libraries we use now for everything else. I seriously doubt that we're going to give all this up, just to meet some level of so-called "semantic" purity.
All I am saying is that a good long term solution to the kind of markup Google produces does not lie with WAI-ARIA. It approaches the problem from the wrong angle and therefore does not give an effective solution.
Anne, my change proposals somehow have become conflated with ARIA. That was a mistake on my part, because I focused on addressing the editor's rationale, which was focused purely on the accessibility of the elements. I shouldn't have tried to respond to his rationale.
I'm the one that questioned the existence of elements like progress, and I'm most definitely _not_ part of the accessibility community. My questioning of these elements has _nothing_ to do with accessibility (no offense to accessibility folks), and everything to do with understanding today's developer community and the state of the art.
of course we know that it approaches the problem from the wrong angle, but so does the current markup that's used by, say, google. if their argument currently is that "inputs/buttons can't be styled as much as we want", then an interim solution - while browsers, CSS WG, or whoever give enough flexibility to achieve that styling - that can make the horrid markup they use a bit more accessible today (for those using modern screen readers, for instance) is to simply inject WAI ARIA into their already crappy markup. it's not an either/or...using ARIA today while waiting for the styling issue to be solved tomorrow...
If CSS had been given the resources wasted on ARIA over the past several years, we could be using proper form controls with all the styling we wanted today.
Far from being a solution, ARIA is an expensive distraction from Web Accessibility and useful innovation.
(I’ve blogged some more thoughts in Supporting the Clean Markup Plea. Good to see your blog getting active and relevant again this year, Anne!)
This is a classic example of what we call the perfect being the enemy of the good. Yes, we know it'd be better for all involved if the elements handled accessibility natively, which is why we're generally against the proposals to remove them. I still don't see any hurry in the WG to establish those semantics, much less implement them, before HTML5 is final. Which means, if we want to lay any of the groundwork in web content or assistive technology, we need to do it ourselves. So we did. If not for ARIA, you get to tell users with disabilities, sorry, maybe you can use the web later. That tends not to go well.
The other side of this is that it will also apply to content that hasn't been fully updated for HTML5. I'm sure you're aware that large swaths of the web won't immediately be updated once HTML5 is done. But with ARIA, they still have a shot at being fixed. The idea that you just tell authors to change elements is just as much of a pipe dream as telling them all to implement ARIA in all of their components. I fully hope for a day where ARIA genuinely isn't needed. But that day is years and years away.
Sidebar: Ben, I see you've adopted Hixie's "black is really whiter than white" argumentative style. Good luck with that. The fact is that the vast majority of the work has been done by people who are focused on accessibility problems, not CSS, a fact for which your only response need be "thank you for freeing me to piss and moan about the existence of stuff I couldn't be arsed to help with."
Ben Millard, couldn't find a comment box at your place. Interested in the bullet list you provided in your post:
Ben, do you use a framework library, like jQuery? Would you say that's spaghetti-like code? I think that would surprise John Resig. Would certainly surprise me.
Most of the framework libraries I've seen, and used, are clean, compact, well designed, and definitely well tested. Most of the framework libraries, such as jQuery, have implemented ARIA internally--working with experts in the field to ensure they get it right. I know that ARIA is being integrated into jQuery UI.
When you use something like jQuery, not only does accessibility come with the library, so does a lot of other functionality, saving you time on your application.
I look at the state of the art for these libraries today, and what you say doesn't make a lot of sense. The only thing I can think of is that you don't work with JavaScript all that often. I don't know what your background is.
I'm not an accessibility person, as I've been told repeatedly this week. But I know enough about web technologies that your statement about how the focus on ARIA has detracted from CSS effort has no merit--especially considering that it was the browser companies that initially balked at CSS and form elements. Even now, there's nothing stopping the CSS group from working on styling the elements. They just don't seem interested.
But it's not either/or. I am confused as to where you got the impression that the work in one area is adversely impacting on the work in a completely separate area of interest.
As for my change proposals to remove these elements, I'm doing what should have been done a long time ago: putting these elements through a rigorous test to determine if they're essential, or just some cruft that got thrown in the spec, in the wild cowboy days of WhatWG glory.
Every new element is the spec should be proven, individually. If its worth can't be proven, if there is no solid rationale for its existence, if we can't objectively evaluate it on the basis of its cost/benefit comparison, it has no place in HTML5.
We should use the discipline we practice with our code, when evaluating HTML5.
"All I am saying is that a good long term solution to the kind of markup Google produces does not lie with WAI-ARIA. It approaches the problem from the wrong angle and therefore does not give an effective solution." - Anne
Exactly!! However, since we don't today have all of the elements we need or could use, we need a "bridging" solution - something (a bridge) that connects us from where we are TODAY to where we want to be TOMORROW. Without that bridge, we have a divide. (Shifting all of this into JavaScript and CSS, as some are suggesting, is a fools errand. That we can do it today is great, but SHOULD we be doing it that way? Nope, which, I believe is what Anne is actually stating moving towards the future)
"If CSS had been given the resources wasted on ARIA over the past several years, we could be using proper form controls with all the styling we wanted today." - Ben Millard
WASTED? The alternative being, what, do nothing? Perpetuate bad practice? If Ben had spent any time working on the problem, rather than standing on the side-lines and taking uninformed pot-shots at those who are actually working toward a leveling of the playing field, I could take him half-seriously. Unfortunately, that's not the case. (It is also worth noting that much of the 'resources' that have been applied to ARIA have been volunteer resources - volunteers who want the web to be accessible today, not down the road some day. Think work in CSS is moving too slow? Do something about it besides complain!)
Sadly, Ben simply reflects the view of some developers out there who think they know about accessibility, but haven't really bothered to try and understand the topic. (The same class of developers who figure they can test something once in NVDA, and then suggest the job is done.)
Go ahead Ben, don't bother using ARIA if it offends you so much. Anyone who even would suggest using this:
alt="'Search Mail' button has silver gradient background surrounded by a thin, dark border with rounded corners." - http://projectcerbera.com/blog/2010/04/aria-plea
...clearly hasn't spent any time at all trying to understand the issues of web accessibility. Does anybody but a graphic designer really care what your button looks like? Yes, design is important, but for a non-sighted user, do you really think they care what color your button is? Can they even fathom what "gradient" is, let alone "silver"? And what does rounded corners have to do with any part of functionality?
I don't know whether to laugh or cry...
"When you use something like jQuery, not only does accessibility come with the library, so does a lot of other functionality, saving you time on your application." - Shelley
...and when that JS library gets separated from your source code, then what? Or has RSS and re-purposing of web content become too passé these days, that 'copy-and-paste' has completely disappeared? And while jQuery has gotten considerably better with regard to ARIA implementation, there is a reason why AOL and the European Commission (in the context of the ÆGIS project - Open Accessibility Everywhere: Groundwork, Infrastructure, Standards) is paying to have jQuery UI's ARIA holes plugged; when it comes to the contributed modules it's a real crap shoot with little assurance that contributing authors even bothered to understand what ARIA is, never mind actually use it in their code development. Glibly suggesting that authors can use jQuery today and not have to worry any further about accessibility sets us back so far I want to cry.
Having accessibility constructs external to your base code is the wrong place to put it: the fact that sometimes we have no choice but to do so today is unfortunate, but a pragmatic choice given the alternative. Continually suggesting that the primary place for accessibility is with JavaScript libraries is simply wrong. Period. The End. Ensuring that JS libraries are accessible is important, and ARIA helps hugely there, but if we can move accessibility closer to the content code-base, we should, as it is more efficient, simpler, and easier to implement.
Shelley, you've admitted that you are not an accessibility person, yet you continue to argue against the collective group-think that is that community as if somehow you know better. Why? Do you think that all of the experienced people who have contributed towards web accessibility (including ARIA) for nearly a decade are somehow less knowledgeable than you? That they haven't weighed the pros and cons of your current thoughts already? That they aren't aware of both the strengths and weaknesses of ARIA? Really?
John, why are you so angry at my change proposals?
The Accessibility Task Force didn't even have them marked for following in the group. It has been mostly disinterested about them.
I don't even think most of the group has a clue which elements are being discussed in the change proposal. They think they're all interactive.
I'm not sure if folks are pissed because I actually dared to write a comment about accessibility, or if it's me, personally, they don't like, but they were relatively indifferent to these bugs and issues before now. I think Laura had the right of it: Ian coaching his rationale in accessibility was a red herring -- and it worked.
Well, I guess we'll see when the counter proposals, or should I say mega counter proposal is written.
Personally, not being an accessibility person, and only being a lowly developer, I think you do the WAI-ARIA a disservice by your comments. But that's your prerogative.
Mine is to no longer continuing these bouts in comments. Nothing is being accomplished.
Anne, I agree that native elements are much better than semantic sugar. But ARIA works today (has been working since 2006 in Mozilla with NVDA) while none of the new HTML5 elements is accessible yet. In a sidenote I wonder why accessibility isn't an integral part of browser development but still appears to be an afterthought, but that's a different issue.
Still ARIA is often the only way to add relationships between elements, liveregions are the only way to inform users of content changes accessibly, and ARIA is perfect for marking up elements that have several meanings, for example at flickr where headings can become focusable input fields (keyboard accessible with tabindex). A progressbar is simple, but how would you solve these examples with HTML5?
And @Ben, comments are turned off in your blog and you don't seem to have a twitter account; apparently you care about accessibility, but your inept alt texts show that you have only superficial knowledge. It's OK that you don't get ARIA, but please try to learn more before accusing others of misusing things that you don't understand. You could simply ask Steve about those contradictions. I believe in the right context they make perfect sense. ARIA is not about CSS layout, it's about semantics and behavior. That's why it's built into most JavaScript frameworks, making also a case against the "top 500 for each country" statement.
@John and Martin: I believe Ben was making a sarcastic comment based on the fact that the original text had "button" in it for no good reason.
Random note: Google does the ridiculous bullshit markup because it works deterministically in every browser they choose to support. Their UIs are generally machine-generated by their GWT Java library. Even if we added proper CSS controls over form styling, Google wouldn't be able to change for a long time.
We should still do form controls, though. I want to take that on at some point, though perhaps someone from Apple would be better suited for it.
"the original text had "button" in it for no good reason"
An img element used as the underlying markup for simulating a user-interface widget could be used for a variety of different things other than a button. A triple-state checkbox for example, perhaps even a slider doohickey, in both cases the significance of both receiving focus and clicking it changes. For that reason, it's a good idea to explain what the img is being used for, and the word "button" is a succinct explanation of the functionality imbued.
My blog isn’t important enough to have a comments system, imho. :) I’m using it so I can correct any factual or technical errors which are pointed out. (So far, none have been.)
I’ve added a response to the specific comments to that entry.
Ben, trying to have a discussion across weblogs is ... fragmented.
You wrote to me:
Comparing kilobytes of JavaScript and the resulting DOM with a (currently hypothetical) HTML+CSS equivalent would indeed make the former look like spaghetti code. To my mind, at least. More to the point, the example of Gmail’s simple image button and simple text link given in The Paciello Group’s article are completely possible and widely compatible using straightforward HTML+CSS. Tab describes them accurately, imho! And that’s a best case scenario for the scripting side of things. From my experience of doing WCAG audits and poking my nose into the source code of hundreds of websites during HTML5 research, JavaScript controls were usually bespoke kludges which only supported IE6. That may be changing but remember the The Long Tail effect and Legacy Content Problem. jQuery UI is a branch of jQuery, as I understand it. They are targeting “Full support for Accessibility WAI-ARIA [at the] end of 2010”. So the current version doesn’t have that. Not sure if the main project has it at all. Perhaps you were thinking of Dojo?
First, I would suggest you not use the term spaghetti code if you don't know what it means.
Second, I don't care what Google does with its stuff, that's between people and Google. Unless Google hires me, I have no interest in being an evangelist for the company.
Ian works for Google: ask him about the approach the GMail developers and designers are using.
As for jQuery, you might actually to look in the code for jQuery UI before saying it doesn't have any ARIA. It does. It did before Dojo, though Dojo has been catching up.
The AOL project is to find and fill any gaps, smooth over any rough edges. Personally I'm hoping the Paciello Group will write up a case study on the work after its finished. It would be exceptionally good training material.
John,
Though I’m not keen on detracting from the subject at hand, I feel obliged to say a few words on behalf of Ben Millard. I don’t know him personally, but we’ve been involved in several online discussions and he’s offered me advice on a few occasions, and I feel that your remarks about him are rather unjust. In particular:
Anyone who even would suggest using [a code sample excerpted from Ben’s blog] clearly hasn't spent any time at all trying to understand the issues of web accessibility. Does anybody but a graphic designer really care what your button looks like?
This strikes me as an unintentional traducement on a couple of counts.
First, from your response, I doubt that you understood the context of the image in question. Ben’s aside related to part of an article from the Paciello Group that explicitly concerned the visual representations of certain design elements and the code used to achieve them. In particular, the image whose alt text you excerpted was a screenshot of Google’s search button in Gmail. As someone with both the occasion (i.e. a two hour commute by bus with a BlackBerry and patchy signal to keep me company) and inclination to read such articles, I can safely say there’s no contest over whose alt text I consider most edifying or useful.
Also, saying that Ben “hasn't spent any time at all trying to understand the issues of web accessibility” stretches presumption to breaking point, and perhaps you will acknowledge this in retrospect. For one thing, I don’t see how you can possibly comment on how much time Ben spends on anything; but in any case, you are quite wrong. For one thing, he’s contributed research into data tables for the HTML5 specification, as well as his own "smart colspan" algorithm for associating data cells with headers. (Heck, just do a Google search for “Ben Millard tables”.) I'm not sure what your standards for “spending time” and “understanding” when it comes to web accessibility, but it’s my opinion that he has applied himself with vigour.
John,
I too feel it necessary to say a few words in Ben Millard's defence.
To say that he "hasn't spent any time at all trying to understand the issues of web accessibility" is an understatement of the highest order.
I first ventured into the world of accessibility some two years ago. At that time, I was fortunate enough to stumble across Accessify Forum. I was even more fortunate that Ben was an active member of the forum.
I can say, with all honesty, that Ben is responsible for about 70% of the knowledge I now hold and about 90% of the commitment I have towards accessibility on the web.
Plus, I would that say that 3802 posts at Accessify Forum displays only a fraction of his understanding of "the issues of web accessibility".