Who’s Using ARIA?

Tweet

A square peg in a round hole

And I don’t mean developers, I mean real people — actual users, who are browsing the Web with assistive devices and making use of ARIA enabled applications?

See, when I first researched the question of accessible Ajax for The JavaScript Anthology, back in 2006, there was no such thing as ARIA; there was only the early draft ideas that would eventually become it, based largely on work done at IBM.

And I was unimpressed. Not because of any specific details, but over the entire concept behind it — the idea that all RIAs needed to make them usable for screenreaders is more information seemed naïve.

And now that we have a formal specification, with browsers and screenreaders that have working implementations, I ask the same question — are RIAs really appropriate to assistive devices if only they had that role and state information, or are we trying to force a square peg into a round hole? Are we just adding layers of information on top of a paradigm that is fundamentally incompatible with the target devices?

What my question really comes down to is, can any Ajax-based application which requires an API to give the consuming device enough information to make sense of it, possibly be better than what we had before — where you submit a form and you get a new page in response — something that generations of devices were well able to comprehend.

I’m not trying to dredge up my stop using Ajax argument again — not at all, I accept that Ajax is here to stay, and welcome it as a valuable addition to the programmer’s toolkit. But the hype has yet to calm down, and Ajax is still over-used. The question of to what extent Ajax applications are expected to progressively enhance from static applications is still very much an issue, as the bulk of the comments in one of Craig’s recent posts highlighted all too sharply.

So where are the ARIA users? And what do they think?

It’s an honest question, because I really don’t know. Is there any information? Have any studies been carried out, that convincingly answer the question of whether ARIA enabled applications are a better user experience for people using assistive technologies, compared with conventional post-and-response style applications, that RIAs should otherwise be expected to degrade to?

Is ARIA really the way forward, or is it just a solution looking for a problem?

Get your free chapter of Level Up Your Web Apps with Go

Get a free chapter of Level Up Your Web Apps with Go, plus updates and exclusive offers from SitePoint.

  • http://www.optimalworks.net/ Craig Buckler

    Interesting post. I’d be amazed if there many ARIA users, mainly because few browsers and web applications follow the specification.

    There’s certainly a lack of decent ARIA code examples and the ones I have seen are fairly nasty. Progressive enhancement using standard HTML would have resulted in less verbose code that was cleaner, easier to read, and worked in all browsers.

    HTML5 has also muddied the waters a little. Many of the JavaScript/Ajax controls we use now will be natively supported. An HTML5 browser/screen reader will know how to present a date picker so there’s little need for additional information. Universal HTML5 support may be years away but so is ARIA.

  • irama

    I can neither confirm or deny the existence of ARIA users, but I don’t see it as a relevant argument to discount the value of ARIA itself. Regardless of current active usage, ARIA serves an important role for conscientious RIA developers.

    There are many reasons developers misuse the markup we have available (for example: using a link as a “button” to control a widget). This may be due to a lack of semantically appropriate markup choices, inconsistent browser rendering of the appropriate markup choice or even ignorance of the appropriate choice. This type of misuse, while not to be encouraged, is extremely common in web applications and sometimes a necessary evil. In these cases, ARIA can go a long way to clarifying the intended semantics.

    Like any best practice technique, only the conscientious will bother with ARIA, but it can’t be denied that it fills a gap that current markup and presentation languages leave relatively open (and rightly so, as this is not their purview)… ARIA describes the semantics of behaviours, and it does a damn good job!

  • http://www.brothercake.com/ brothercake

    With respect, you’re missing the point. The very existence of ARIA is a reason not to build apps on a basis of progressive enhancement, because assistive technologies are the principal reason for doing so. If a technology exists that makes progressive enhancement unecessary, then people will stop doing it. But if that self same technology fails to serve its audience, then they’ll have stopped doing it for the wrong reason, and thereby created an accessibility barrier.

    And neither is it a case of conscientiousness. Only a fool spends their time implementing something which serves nobody. No professional developer, however conscientious, is going to invest the time it takes to learn and implement this technique unless it can be established that there’s a useful purpose to it.

    Is it a failure of conscientiousness to build apps that don’t provide all the same bells and whistles to Mobile IE as they do to desktop Firefox? Of course it isn’t, but those users exist, so why isn’t it?

    I agree that ARIA meets its own brief very successfully, in technical terms – provides the role and state information that it sets out to provide. But has any good purpose actually been served by doing so, that’s the question. Does it provide a good user experience? Does it provide a better user experience than an app that works without any scripting?

    You say it provides an important role, but it only does so if it provides a better user experience. Think of like video captioning for the deaf – that provides an important role, but only insofar as the subtitles are useful to their target audience. There’d be no point implementing captions in a language that none of your audience speaks, just for its own sake, would there?

  • ImBuzu

    In my opinion, trying to make some apps accessible is just as foolish as trying to make photoshop accessible to the blind. It really makes no sence.

    I’m not saying that we shouldn’t develop from an accessibility point of view, but that we shoul be concious about when it becomes just unnecesary to try implementing more accesibility than that that is required by the target of our application.

  • http://www.brothercake.com/ brothercake

    So give us some examples of apps that it would “foolish” to try to make accessible, along with the kind of accessibility you’re talking about, and the ways in which the app would be untenable to the target group.

  • irama

    With respect, you’re missing the point.

    I have a lot of respect for your work and articles you’ve written in the past, but in my initial comment I had to stop myself from making a similar statement, as I believe you’re missing an important point about accessibility, it’s not just for humans.

    The very existence of ARIA is a reason not to build apps on a basis of progressive enhancement

    This is a flawed conclusion. ARIA cannot provide the same benefits as progressive enhancement. I’m a strong supporter of PE, combined with ARIA to further enhance accessibility.

    You say it provides an important role, but it only does so if it provides a better user experience.

    This is another non-sequitur. I agree that a better user experience is one of the important benefits to be had from ARIA, but accessibility goes beyond human users.

    Is ARIA really the way forward, or is it just a solution looking for a problem?

    The problem is clear. As touched on in my previous comment: Current standards leave gaps around the semantics of behaviour and markup is often misused in the development of web applications. ARIA addresses these issues well, so yes, I believe it is the way forward.

    The dramatic truth is, ARIA is already implemented to different degrees in modern browsers, but if we (as developers) don’t actually use it, then we are dooming ARIA to not meet it’s potential. I have great faith that ARIA is providing a better user experience for users already and will do so for many more in future, but we all need to get behind it for it to have a chance.

    I’m gratified to see so many JavaScript frameworks embracing ARIA and incorporating ARIA semantics into their default offerings. This way, even the less conscientious developers will be promoting adoption of the standard. But the more support it has, the better chance it has of making that real difference to more users.

    Brothercake, you wield great power, many readers (who may also be developers) will listen to what you have to say and may even abandon ARIA based on your dismissal of it’s value. I’m disheartened that you are not promoting such a worthy cause.

    I respectfully request that you zoom out to the big picture: No matter what current usage statistics are, ARIA has great value and even greater potential. Or, in the words of Colonel Pogue from Full Metal Jacket …jump on the team and come on in for the big win!

  • http://fvsch.com Florent V.

    I believe you’re missing an important point about accessibility, it’s not just for humans.

    Hum. How so? If i read the WAI’s definition, Web accessibility is for humans; what’s more, it’s for disabled humans. Of course, you’re free to disagree with the WAI (i don’t).

    ARIA cannot provide the same benefits as progressive enhancement.

    True enough. ARIA is an accessibility mechanism. Progressive enhancement (especially if you’re thinking of unobtrusive JavaScript) is a compatibility mechanism, that may have incidental accessibility benefits for some use cases.

    They’re obviously quite different.

    I’m a strong supporter of PE, combined with ARIA to further enhance accessibility.

    Doing an HTML/HTTP-only interface, then adding Ajax for usability, then adding ARIA to make the Ajax accessible… covering all bases is nice, but this looks like a development and maintainability nightmare.

  • http://www.optimalworks.net/ Craig Buckler

    @Florent V.

    Doing an HTML/HTTP-only interface, then adding Ajax for usability, then adding ARIA to make the Ajax accessible… covering all bases is nice, but this looks like a development and maintainability nightmare.

    I think what brothercake is saying (correct me if I’m wrong) is if you build an HTML request/response page, it’s already accessible. Progressive enhancement such as Ajax can then be added, but there’s no real need to implement ARIA because accessibility was assured anyway.

  • http://www.brothercake.com/ brothercake

    Yes, that is exactly what I’m saying.

    Regarding the point about non-humans: I agree with Florent, accessibility is for humans. Now I don’t personally limit it to humans with disability, but machine-accessibility is an entirely different subject. What is there in ARIA that provides for non-human consumers? I thought that’s what microformats were for.

    I’m not dimissing ARIA at all – if you think I am then you’re putting words into my mouth – what I’m doing is critically questioning it. Ultimately, my motivation here is that I am very keen to start promoting ARIA, and have been all along, but not until I’m convinced of its value. And to be convinced of its value I need to hear from its users.
    And it doesn’t need to be statistically significant – even one avid user might be enough to convince me.

  • http://www.brothercake.com/ brothercake

    btw – I really don’t see that I have to censor my opinions just in case the easily-led should draw the wrong conclusions from what I say. I don’t have anything like that much influence. And even I did, it’s not my responsibility.

  • ImBuzu

    bothercake, One example, just tu support my point, is the applications from aviary (http://aviary.com/) I would really make no sense to try making the apps accessible to the blind would it?

  • ImBuzu

    sorry, I meant brothercake, not bothercake… My mistake…

  • irama

    Hey all, really enjoying the discussion here. I think we’re getting closer to understanding where each other are coming from. But I have a few more clarifications.

    @Florent V: If i read the WAI’s definition, Web accessibility is for humans; what’s more, it’s for disabled humans.

    You have misunderstood me. I didn’t said accessibility is not for humans, of course it is. I said it’s not just for humans. For example: Some disabled users rely on Assistive Technologies (AT) to access the content, this means the content must be machine understandable. This part of accessibility is for the AT (for the machine), the AT then relays pertinent information to the human. And the other side of accessibility for non-human purposes can be best summed up by Atul Varma, please read: The Open Web is Magic Ink. So my point is, the added semantics ARIA provide great value in terms of accessibility regardless of the total number of current users (which haven’t even been established yet).

    @Craig Buckler: if you build an HTML request/response page, it’s already accessible. Progressive enhancement such as Ajax can then be added, but there’s no real need to implement ARIA because accessibility was assured anyway.

    Think about that statement again, carefully, because this is a common misunderstanding of PE. PE and Ajax can take a perfectly accessible markup+style page and diminish (or even ruin) it’s accessibility. Unless the user is in the habit of disabling JavaScript (and only some disabled users will do this) then a PE application can become quite inaccessible. This is where ARIA steps in to clarify the more complex behaviours introduced by the PE. PE + ARIA work very well hand in hand to cover all bases.

    @brothercake: I am very keen to start promoting ARIA, and have been all along, but not until I’m convinced of its value. And to be convinced of its value I need to hear from its users.

    Fair enough. I think we can agree this is a Chicken and Egg standoff. I’m going to keep using and promoting ARIA in the belief that this chick is gonna’ hatch :)

    Peace.

  • http://fvsch.com Florent V.

    @ImBuzu: True, making some apps accessible to the blind makes no sense. Most notably graphics editing apps like some of those Aviary apps. But there are a lot of other apps that are not about manipulating graphics. If you build a sound editing app, maybe that one could be accessible to that demographic too?

    Moreover, a simple photo editing app (or even a complex one) would be accessible to more users if it was keyboard-accessible. Cropping photographs, selecting filters and parameters… this can be done with the keyboard, if the app is developed and tested for that use case too. (There is not much in ARIA about keyboard accessibility, except for the redefined use of the tabindex attribute.)

    My point is that Web accessibility is made not only of generic guidelines (like, use semantic HTML), but also of guidelines specific to one or a few use cases (and disabilities).

    It may be interesting to drop the idea that you build “normal” websites for “normal” people or usage, then ask yourself “can we make it accessible?”. One approach that could be more effective is, from the start, to ask: “What use cases can we provide for? Mouse only? Notebook trackpad? Keyboard access? Screen reader access? Smartphone access? etc.” I’m not sure that’s the best way, but it’s an idea.

    @brothercake: You say that if a Web app is developed using Ajax as progressive enhancement, then it’s accessible. That’s highly debatable.

    1. Modern web apps are not just about Ajax. Many of them have JavaScript widgets that help users enter or manipulate information. Sometimes degrading the feature to an HTML form works. Sometimes it won’t. If you build an audio editing app, replacing a track timeline that the user can select from with an form with two inputs to enter the start and end seconds of a selection… well, that won’t work well enough to make it an accessible alternative. (I’m not sure ARIA could be use effectively for that one example, though.)

    2. Most screen-reader users have JavaScript enabled. Most people who use the keyboard (or a simplified keyboard) exclusively will have JavaScript enabled. So if your app has JavaScript updating the DOM in a significant way and doesn’t use ARIA to notify screen-reader users… the app won’t work for those users. And if you have JavaScript(+HTML+CSS) widgets that users can only interact with using a mouse or trackpad, the app won’t work for keyboard users. As users with accessibility needs are more likely to use JavaScript than not, maybe it’s a better solution to NOT use progressive enhancement, and to use ARIA instead? (That’s an open question.)

  • ImBuzu

    Florent V I’m not saying we shouldn’t care about accessibility. I am an accessibility/usability evangelist my self. What I’m saying is that there’s a point where trying to reach a 100% accessibility is just not possible. Of course, that doesn’t mean we shouldn’t try to achieve the highest level of accessibility. It is just a mater of knowing when it is possible and necessary, and when you are just wasting your time.

  • http://www.brothercake.com/ brothercake

    You’re both right – assistive techologies do indeed fall through the net of progressive enhancement, because they are script capable browsers, but they still can’t cope with many scripted interfaces.

    I should have been more explicit – building on a basis of progressive enhancement *will* provide accessibility to assistive devices, but *only* if you provide the non-script version as an explicit user choice. In other words, it’s not enough to allow PE to work naturally, you have to provide an option whereby you remove the scripting yourself when outputting the pages.

    I generally advocate doing this as an explicit user choice as part of a signup process; although 9 times out of 10 I avoid the issue altogether just by not using Ajax.

    As far as widgets go, I’ve never yet encountered a widget that couldn’t be represented with existing form elements, with a little creative thinking. Though I’m prepared to be proved wrong on that.

    Oh yeah, and ImBuzu – that’s all cool; I was just making sure you’re not one of those people who says that when really it’s just an excuse for why they don’t have to be bothered ;)

  • irama

    @brothercake: I should have been more explicit – building on a basis of progressive enhancement *will* provide accessibility to assistive devices, but *only* if you provide the non-script version as an explicit user choice.

    That could work, but it feels similar to forcing users to choose “Flash or no Flash”. I’m keen to avoid that kind of fragmentation where possible and work towards All for OneWeb and OneWeb for All.

    This is precisely the gap that ARIA fills, why it’s not a solution looking for a problem. ARIA has the potential to make a PE page or application directly accessible, it largely removes the need to relegate some users to the accessible alternative.

    Happy One Web Day!

  • http://www.brothercake.com/ brothercake

    Okay, but … does the ARIA enabled interface provide a better user experience than the non-scripted interface? If it does, all good; but if it doens’t then it’s not the right approach. This is exactly where we came in, and we’re no closer to an answer, because we haven’t seen any real evidence from users, just conjecture from developers.

    There’s nothing fragmented about the scripted/non-scripted approach. It isn’t an alternative, it’s the same, just a different mode of interaction.