I just wanted to set a few things straight regarding a blog post by Jeremy Keith titled Ariability. He’s definitely right that there some amount of opposition to WAI-ARIA. Not necessarily against the idea of providing a low-level accessibility API (though there’s skepticism about that too), but more the way things are defined and integrate with the rest of the platform.
E.g. Jeremy may be right that the search role applies to the form and not the input element, but that does not mean you need role="search". If you have <input type="search"> you can just specify that its associated form element implicitly has the search role obsoleting the need for that particular role. This would encourage people to use an API (<input type="search">) that benefits everyone rather than just those using assistive technology. Since WAI-ARIA is nothing more than a mapping from markup to assistive technology APIs it is worth considering if we can make the mapping implicit now and then based on other markup features to save authors the hassle of having to worry about it. Because usually, authors won’t as there’s no tangible benefit to them.
His other point was about the banner role versus the header element. However, the comment from Ian Hickson is not about that role, it is about the heading role which simply duplicates an existing HTML feature. WAI-ARIA duplicates other existing HTML features as well, e.g. the checkbox role. However, for that role there is sufficient reason as normal checkboxes cannot be styled properly (yet) and therefore sometimes authors create their own which in turn leads to the need of being able to expose state and such to assistive technology. However, h1 and such can be styled perfectly fine. Furthermore, how heading interacts with the existing heading elements is left completely undefined so it is not clear how to expose a document outline to assistive technology when a document uses both HTML heading elements and the heading role.
How the checkbox role interacts with existing HTML features is also a point of contention. E.g. given <input type="radio" role="checkbox"> the WAI-ARIA specification suggests that assistive technology should get the checkbox role where the rest of the world will see a radio button. It seems a thousands times more likely that the author made a mistake there than that he did the right thing, especially since most often the author and most of his visitors will not know at all how assistive technology interacts with the widget.
We would love to have a more open debate on this, but the WAI-ARIA group does most of its work behind closed doors. Henri, Ian, and I have submitted a bunch of Last Call comments on the WAI-ARIA specification, but the dialogue about those comments happens in private. I think it would be much more productive if we could have an open direct dialogue with members of the group similarly to how the SVG, HTML, and CSS Working Groups operate rather than giving a comment and waiting for some black box process to come up with an answer.
One of Jeremy's alleged differences between banner and header is that banner is unique per document whereas the other can be used multiple times in the same document
. This claim depends on an incorrect conflation of the notions of an HTML DOM and ARIA document. You may have zero or more header elements in a HTML DOM. You may have zero or one banner descendants of a an ARIA document or ARIA application. However, you may have multiple (and nested) ARIA document instances or application instances in a single HTML DOM, so you may have multiple banner elements in an HTML document too.
The hostility towards landmark roles boils down to this:
It’s late 2007. You are a browser accessibility developer. Which is easier: exposing <div role=contentinfo> to accessibility APIs in a certain way or exposing: <footer> to the same accessibility API in the exact same way? The answer should have been that the two alternatives are about equally easy (perhaps the latter a tad easier but not enough to matter for my point).
It should be a no-brainer that in the long run one would want to have <footer> rather than <div role=contentinfo>, because Architectural Forms are crufty. (Don’t agree with me? Imagine writing all HTML elements like <div html=h1> instead of <h1>. Still not seeing the cruftiness? Really?)
Yet, PFWG pushed developers to implement the cruftier alternative. Why? I don’t know of a public explanation. Was it NIH? Was it concern that Firefox 2 wouldn’t go away soon enough? Was it an axiomatic expectation that ARIA will be adopted soone than HTML5?
In any case, it seems that we are going to end up with more crufty language design where it would have been avoidable. This kind Conway’s Law situations in the W3C are not cool.
What is being said and what is being heard? One camp think accessibility matters so much that they want a technology that can be implemented now, and in many ways they are correct. The ARIA train has left the station. Firefox 3/JAWS 10 users benefit today.
Then comes the good people associated with WHAT WG and all they see is problems! Causing the people in the first group to cry that the people in the latter group don't care about accessibility, suffer from the NIH-syndrome, etc.
Having followed you guys for a few years now, I know that is not true, but spec writing people need to see themselves with the eyes of non-spec writing people once in a while. Because what is being said is not what is being heard.
It's Spring, 2009. WAI-ARIA's deadline for comments for the "Last Call" stage is Friday of this week. All the major browsers are supporting significant amounts of the Last Call specification TODAY. Major script libraries (YUI, DOJO, jQuery) are adopting and incorporating the specification and producing workable and accessible content that is already in full production on "A-List" websites. Outside 3rd-party groups are testing and reporting on implementation wrinkles and reporting back to the W3C. Ideas, suggestions and recommendations around ARIA are discussed civilly and evenly, with no autocratic leader deciding when and if a particular feature will see the light of day.
Meanwhile, across the street, a small group of conspirators (funded for the most part by browser manufacturers who have their own agenda), led by a self-professed benevolent dictator who has publicly stated that consensus is not how he will edit his version of a draft specification, are working on a specification that will still take a number of years to reach Last Call, then Candidate Recommendation/Proposed Recommendation/Final Recommendation. This small group decides that prior art, produced externally from their internal discussions, is somehow inferior to their thoughts, and thus dismissed and/or stalled according to their dictator's publicly stated procedures.
As a standards aware, progressive developer, whom should I listen to? It should be a no-brainer that, faced with these choices, and wanting to do the right thing now with the best solution possible, I know which way I would go - with the more mature specification.
Consensus requires both give and take. WHAT WG however does not want to create by consensus - they've publicly (via the editor) said as much. They are dragging their feet, and throwing up quibbles and insignificant arguments (do I really care if it's 'contentinfo' or footer? - especially when my wysiwyg editor will add the actual value to the source code anyway?) to block or stall the integration of ARIA into HTML5. The argument is a re-direct: smart consensus builders would take work previously wrought and import it as-is - it has been discussed, debated, use-case tested and finessed over a significant period of time. But ARIA wasn't done by WHAT WG, so it's wrong, or bad, or 'conflicts'. Pisha!
And so lately, I've come to my own conclusion that (and here's another gripe of mine) since there is really no negative consequence to authoring non-conformant HTML5 anyway*, that I will simply cherry pick what I want and don't want to use, and let the almighty market decide who is right. ARIA works today. That frankly is good enough for me - to hell with HTML5 as dictated by one small group who would rather argue than build consensus.
(*outside of an error message from an experimental validator)
John, so you’re dismissing our arguments based on where they are from rather than on their merit? That’s lame. Hopefully the PFWG does better than that.
I agree with you that validation is just a tool by the way. The issues with WAI-ARIA, however, are mostly of Web browser implementation nature, not necessarily validation (although there are issues there too).
I must say that do I see the problems you are pointing to, Anne. ARIA could in theory lead to less correct HTML coding because one rely on ARIA to tell which element is a heading and so on.
But when it comes to that last paragraph in your posting, about openness, then I am not so sure. Like Lars Gunther, I think there is a difference between what is said and what is heard, because one's experiences filters what one hears. HTML 5, with its (socalled) openness, is not an outright success. For some listerners, openness might sound like "we want control over you". (Even the leader of the well liked (by the WHATwg) MatMLwg said, in the HTMLwg recently, that it is they who decide how linking is supposed to work in MathML. I thought it was striking that he said so, when we consider how positive the WHATwg group viewed them - as opposed to the accessibility group(s))
That something happens in the open or that one is severely honest, is not the same as openness. Or to put it another way: That you decide to perform your meeting in an open place does not mean that we all have a duty to care about what you say or decide there. It doesn't even mean that you have any right to blame us for not having protested against what you decided there.
I think we need a better definition of what openness is. There is a difference between transparency and openness. Transparency is about the control aspect. Openness is about "I thrust you, and you thrust me".
Much of the openness side of the HTML 5 process seems to have been motivated by the control and exposing aspect. However, I think that real openness is often much easier to get in a closed forum. However, the forum can be transparent, but still closed. THat is how many of use thought the HTMLwg would be. But as we know, the editor only sees the HTMLwg as one source of "info".
Anyway, it is important to be aware of how hollow the openness argument now sounds in many ears ... Openness is something you get when you engage in people.
Anne,
I am dismissing many of your arguments based upon the process and procedure that Ian applies (deny, ignore, stall). WAI-ARIA is a mature draft specification that is now at Last Call. You noted that you and others have commented on specifics of the Draft. This is a good thing, and thank you for those contributions, those specifics will be addressed by the PFWG accordingly... (frustrating to be on the other end of the waiting game huh?)
That said, WAI-ARIA is working today - not perfectly, but predictably for the most part; it is being used today, and is part of the living and breathing family of "html" languages whether WHAT WG wants it to be or not. Deal with it. Major corporations are not only using ARIA, but actively supporting it (IBM, Yahoo!) and yet the WHAT WG are tip-toeing around it like it has a bad smell. The real problem as I see it is that the WAI spec has conflicts with the WHAT WG spec, and the authors of WHAT WG are having a hard time with it, because they have lost 'control'. They are realizing that they may actually have to concede to another specification/work-group that is further along in the W3C process and they are none-too-happy.
The other aspect is that, as I am now pointing out to one-and-all, there are no consequences to non-conformant HTML5 (so, I guess tag soup can remain on the menu). Thus, I encourage developers to use ARIA today - on it's merits - and not worry what the WHAT WG thinks or worries about. The benefits far outweigh the consequences (which by apparent design are close to null anyway), so just do it. The latest browsers support, AT is supporting, and industry is adopting - for the average developer, what more do you want?
The frustrating bit is that the Working Group went to Last Call without addressing all known issues first. Not necessarily having to wait for answers. The other frustrating bit is that it is unclear how the comments are handled and that there is no insight into group discussion. I don’t mind waiting.
I don’t see anyone contesting WAI-ARIA not being part of HTML. I see people contesting specifics of WAI-ARIA. So your comment doesn’t make a whole lot of sense to me. (Besides that you attribute all kinds of things to the WHATWG that I don’t think are true.)
And you can scream all you want about WAI-ARIA being mature, but from an implementors perspective it is far from it. And that should be abundantly clear from the fact that they’re working on a separate document to actually define how to implement it. Sure, adoption is there in some user agents, but does it actually match the specification? Does it make sense? Where are the details defined how it interacts with HTML features, et cetera?
Leif, I just want to discuss the issues directly with the WG members rather than submitting an issue and waiting for an answer via proxy. I’d prefer that to happen on a public list so a larger set of eyes can look into the conversation and jump in when appropriate. This may not always work perfect, but it at least makes it clear where everyone stands and what needs to be done to move on.
If anyone with the world view similar to "Unrepentant Hardliner" happens to read this page. Please take a step back and ask yourself what benefits accessibility on the web: Your cathartic diatribes or addressing the issues?
The very same browser vendor that pioneered ARIA (Mozilla) is also working very hard on HTML 5. I have a hard time understanding why we can't have both, without this flaming of each other. And yes - I've seen some flames coming the other way around too.
The louder one shouts, the weaker the argument generally is. Too bad if it comes across like this now, since ARIA is really useful and has a lot of good arguments and use cases!
@Lars Gunther:
My 'diatribes' are borne out of HTML5's authoring group's refusal to accept that there is more than their vision of what is acceptable 'accessibility'. I have previously posed serious questions to this group only to be dismissed, ignored, or belittled on the grounds that I have set expectations too high. I am still waiting to hear (for example) on how they will ensure that the canvas element will not be abused or used to create inaccessible content, as virtually every example I have seen on the web today is not accessible; furthermore these examples for the most part don't even try to reach some kind of compromise or accommodation. This is simply inexcusable (especially since the draft specification insists that 'fall-back' content be present).
You might find my stance offensive and that's OK - I sign it exactly the way I see it. But to be very clear, I do and have in the past contributed to the larger discussion, and FWIW the current 'proposal' for dealing with @alt is patterned almost directly upon a suggestion that I first put forth to the working group (http://tinyurl.com/63dq3r)
Call me fringe, that's OK too - just realize that this is how far the fringe extends: outside of the arcane world of web-heads and spec writing there are many, many more accessibility advocates and 'fighters' who share my militant stance when it comes to ensuring the rights and respect that the disabled community deserves. Heck, by some standards I'm a pussy cat.
@anne k
The frustrating bit is that the Working Group went to Last Call without addressing all known issues first.
I can understand that frustration very well: it's the very same frustration people such as myself have felt when HTML5 implements elements like canvas and video (complete with browser implementations) with little consideration on the impact and 'alternative' solution/content for the non-sighted user. It is the frustration of having existing HTML4.x accessibility features such as @longdesc dismissed without once consulting the PFWG or anyone inside of WAI. It is the frustration of arguing ad-infinitum over @alt - and how again the WHAT WG 'decided' that @alt should be optional without once consulting with the experts community. Yep, know the feeling well - no fun is it?
Are there two interoperable independent implementations of ARIA landmarks, BTW? (I.e. two combinations of browser/OS/screenreader where all the three components are different in the two combinations. E.g. Opera/Windows/JAWS and Firefox/Linux/Orca.)
"Are there two interoperable independent implementations of ARIA landmarks, BTW?"
"Are there two interoperable independent implementations of ARIA landmarks, BTW?"
- IE/Windows/JAWS
- Firefox/Linux/Orca
Excellent. Thanks! I’ll add landmark support to Validator.nu.