Early on in the project, we came up with a set of criteria for evaluating DHTML toolkits. These included:
- Cross-browser support
- Easy debugging
- Event abstraction
- A solid DOM manipulation library
- A strong community and clear roadmap for improvements
Accessibility is a particularly challenging issue for toolkits, opening up a whole new can of worms for Web developers. The ugly reality is that the vast majority of widgets are completely inaccessible to users who can’t use the mouse or who require an assistive technology such as a screen reader. Worse yet, the standards and techniques for DHTML accessibility are still being worked out, and browser support is significantly in flux.
We’ve been involved in the Dojo community for over a year now, assisting with their efforts to make many of the Dijit widgets more accessible. This work includes keyboard navigation, ARIA semantics, and high-contrast styling. The whole team has done a first-rate job on Dijit accessibility, and continue to make excellent progress.
Many of you might remember our initial efforts to use Dojo as the toolkit of choice for Fluid. We built the Reorderer as a Dijit Widget, and used their drag and drop library extensively. Problems ensued. Some were entirely situational; the Dojo community was pushing hard for their 1.0 release and weren’t able to give as much attention to their drag and drop library as we would have liked. Others were architectural; our unobtrusive, markup-driven approach just didn’t fit well with Dojo’s more “JSF-ish” style of widget encapsulation. We genuinely hoped to leverage Dojo for Fluid, but ultimately realized that it just wasn’t aligned with our needs.
With a broken Reorderer and a release deadline looming, we decided to switch. In a week-long sprint, we implemented the Reorderer’s core using YUI, Ext, jQuery, and MochiKit. We were never able to do a full “apples-to-apples” comparison, but we got a pretty good feeling for each toolkit’s various strengths and weaknesses even though we had to choose quickly. YUI’s documentation was exceptionally thorough, and its feature set was excellent. MochiKit provided a nice clean library. Dojo widgets had great built-in accessibility. But ultimately, we chose jQuery because it just fit.
jQuery Just Fits
I also like the fact that jQuery specifically makes it easier to keep your code and markup separate so that they can be changed independently. The browser environment makes separating logic from presentation feasible, and jQuery encourages this by providing quick ways to grab elements in the document and bind handlers to them when the page first loads. jQuery’s UI widgets are built in such a way that it’s easy to support progressive enhancement, allowing your pages to to be built on a bed of valid semantic markup which will degrade gracefully on older browsers, mobile devices, and so on. Here’s an example of how jQuery UI Tabs take advantage of progressive enhancement.
I mentioned the community earlier. The jQuery lists are healthy and active, and there’s a general sense of openness and welcoming from the group. I gather that, in the early days, John Resig took a lot of time out of his day to patiently answer questions, and this has clearly fostered a generous user culture.
How You Can Benefit From Our Commitment to jQuery
We think that a healthy, open Web should include more than one accessible DHTML toolkit. The Mozilla Foundation agrees with us, and have kindly offered us some funding to help mentor the jQuery community on accessibility issues. We’ll help ensure that the jQuery widget set is accessible, and that there are simple tools available to make third-party jQuery plugins accessible.
Fluid is contributing a lot of the code required by DHTML developers to support accessibility in their own widgets and plugins. And other members of the jQuery community are getting involved. We expect a rich set of accessibility and progressive enhancement tools to emerge over the coming months. Many of these accessibility plugins are ready to use now, and we’d love your feedback and suggestions for how we can improve them in the future.
If you’re already using jQuery, Fluid’s components will merge seamlessly with your existing code. Over time, we’re planning to build jQuery plugin interfaces for many of our components, providing a quick and idiomatic way of using Fluid components in your pages.
There’s a lot of exciting action going on in the jQuery and Fluid communities these days. The jQuery UI team is on the cusp of releasing jQuery UI 1.5, which will provide a significant reworking of the widget model and opens the door for accessibility code to be easily shared across widgets. Fluid’s upcoming Infusion 0.3 release is entirely based on jQuery, and we’re already using a pre-release version of their 1.5 drag and drop library with great success. Expect to see upcoming Fluid components incorporate other jQuery UI widgets, and we’ll contributing usability and accessibility advice back to the community.
We recognize that not everyone is going to make the same toolkit decisions we did, so we’ll do our best to ensure that Fluid’s code plays nice with other toolkits.
Oh, and if you live in Toronto and want to contribute to our work, we’re hiring…