On Day 1 of the HighEdWeb conference, one strong impression I got was that everyone is either using or considering using one or more Javascript frameworks to speed up their web development. Javascript frameworks are libraries of pre-written widgets or controls that developers can essentially plug into their websites without having to develop them from scratch.
There are two questions that came up repeatedly at the conference:
- How does a newbie to Javascript frameworks decide which one to use?
- Which Javascript framework is most accessible?
There are many excellent blogs that discuss the choice between frameworks (just Google “Choosing a Javascript framework”). Favorite frameworks, judging by the blogger buzz and by discussions at HighEdWeb, seem to be jQuery, Yahoo! User Interface (YUI), MooTools, Prototype/Scriptaculous, and Dojo Toolkit. Many of the blogs raise excellent questions that folks should ask in considering which framework is right for them. However, few blogs recommend asking whether the framework produces accessible output. To me, this is a critical consideration, and I’ve been pleased to hear it asked so frequently here at HighEdWeb. If websites of the future are going to all be built from the same re-usable code, then the accessibility of that code will have a huge global impact on web accessibility.
So, which Javascript framework is most accessible?
The Wikipedia entry on Comparison of Javascript Frameworks presents a large data table comparing over a dozen frameworks on over a dozen features, including “Accessibility /graceful degradation”. In the current version of this Wikipedia page, frameworks are rated with either “Yes” or “No” on this variable, which would seem to be an oversimplification. I’ve tried below to provide more extensive information about the current state of accessibility for the more popular frameworks.
A key to accessibility of interactive web controls is their support for the W3C’s draft Accessible Rich Internet Applications (ARIA) specification. ARIA addresses the accessibility of dynamic web controls by defining a method by which developers can specify roles and states of custom HTML widgets. Supporting browsers pass this information on to supporting assistive technologies.
There doesn’t seem to be much talk about accessibility within the MooTools or Prototype/Scriptaculous communities, which I suspect would indicate inaccessible code, but I’d love to be corrected. Another framework, Ext JS, has published a Ext JS Roadmap which includes “ARIA/Section 508 accessibility improvements” among the features slated for inclusion in the Ext JS 3.0 release, scheduled for Winter 2008 or Early 2009.
The following is a summary of frameworks that from my perspective seem to be taking accessibility most seriously:
Dojo Toolkit
Dojo was the first framework to have substantial accessibility support. The core widget set of Dojo has included accessibility support since the release of Dojo 1.0 in 2007, including full keyboard support, ARIA support, and support for high contrast mode. According to the Dojo A11Y Statement, they are still “the only fully accessible open source toolkit for Web 2.0 development.” That may be true, but I think one or two of the others may be catching up.
Dojo also includes extensive accessibility documentation in its on-line manual, The Book of Dojo. Becky Gibson of IBM’s Emerging Technologies group is Dojo’s accessibility lead, and she presented an excellent and unbiased paper at the 2007 W4A conference in Banff titled Enabling an Accessible Web 2.0 (in PDF). I spent a few days hiking solo among grizzlies and elk prior to that conference, but that’s another story…
jQuery
The jQuery Accessibility community is actively working to build accessibility support into jQuery. One significant development was Chris Hoffman’s jARIA plug-in, which extended the jQuery object with a set of ARIA methods. In an announcement posted to the community on September 22, David Botter says that ARIA functions have now been integrated into jQuery UI’s core. This would seem to be a very promising new development.
Yahoo! User Interface
Yahoo! has been adding accessibility to its widgets since 2007 if not earlier, as documented in their blog post Using WAI-ARIA Roles and States with the YUI Menu Control. However, their support for accessibility still seems to be isolated, although slowly expanding. In a blog post on October 2 titled ARIA Plug-Ins for YUI Widgets, they announced that “a handful of widgets” now include ARIA support.
Google Web Toolkit (GWT)
Google Web Toolkit is a Java toolkit, rather than a Javascript toolkit, but nevertheless deserves mention here. On September 5, Google announced built-in accessibility support in GWT 1.5, the latest release. Support is provided by baking ARIA roles and states into core widgets, and by providing an Accessibility class that allows accessibility to be added to developers’ custom widgets.
For my own development efforts, I’ve getting my feet wet with jQuery, and as time permits I may have a look at Dojo and YUI as well. If others have firsthand knowledge of accessibility of a particular framework, please share your stories and observations!
3 replies on “Accessibility of Javascript Frameworks”
Wonderful review of accessibility for current web technologies. Please continue to inform the developer community as things progress. Keeping the web accessible to all is very important, and this is a very large step in the right direction!
The Paciello Group has just released a WAI-ARIA Implementation report on JavaScript UI Libraries.
In recent years, I’ve also been building AccDC at WhatSock.com for this purpose, which is a dynamic content management system that enforces accessibility. This too is referenced in the Comparison of JavaScript Frameworks page on Wikipedia.
Additionally, there is a Bootstrapping library available at
http://whatsock.com/bootstrap
That can be used to create accessible interactive components using semantic HTML markup.
It is a misconception that ARIA will make things accessible. If the keyboard functionality of interactive components doesn’t precisely match the ARIA attributes applied to them, then these components will not work accessibly. I’ve recently seen this with GWT, and in many other places.