The original idea of the ARIA Hackathon was to get developers of jQuery UI and experts for ARIA together in one room, connect them, share knowledge and work on the accessibility of jQuery UI.

Meeting at the Inclusive Design Research Centre (IDRC) of OCAD University in Toronto, several members of the jQuery UI team (Richard, Scott, Dan, Jörn), various developers at OCAD (Michelle, Justin, Antranig, Harris), around Toronto (Ates, George, Darcy) and further away (Mat from Boston, Candace and William from the University of Washington and Jerry from the University of Illinois) learned a ton about testing and developing for screenreader users, about the ARIA standard and its process, as well as Mozilla’s efforts on accessibility.

• Colin Clark gave an overview of the work of the IDRC team, including the Fluid project which makes use of jQuery UI.
• Hans Hillen provided a lot of very practical insight on testing and developing with JAWS and NVDA and the ARIA spec and DHTML styleguide.
• Jospeh Scheuhammer, heavily involved in the ARIA standards process, gave insight on how the process works like, how to provide feedback and which documents can and should be used along with the main specification.
• David Bolter provided an overview of Mozilla’s efforts on Firefox accessibility, also covering the state and future of Firefox Mobile.
• Finally Jennison Asuncion demonstrated usage of JAWS on regular websites, giving the spectators (or rather, listeners) a much better understanding of how a blind user actually uses a screenreader. He’s also an incredibly nice guy.

In a group discussion, we defined latest NVDA on latest Firefox as the supported setup for ARIA and acccessiblity, while also testing with JAWS on Windows and VoiceOver on OSX. We will accept reasonable patches for other or older ATs if the code is maintainable and doesn’t break ARIA in spec-conforming ATs.

After the two days of the main event, Hans and Jörn stayed till Friday to work on the keyboard and accessibility implementation of multiple jQuery UI widgets. Jörn also had meetings with Justin and Michelle at OCAD and Bobby and David at Mozilla to recruit them for jQuery UI and the Testing subteam (QUnit, TestSwarm). There is a lot of mutual interest that should lead to a lot more collaboration going forward.

Special thanks go out to IDRC and Colin Clark for hosting the event and Mozilla and David Bolter for funding some of the travel and lodging expenses.

For a mostly complete list of attendees (and links to Twitter and GitHub profiles) and various resources gathered during the event, visit the events page on our planning wiki.

Back in November, we announced the first of many API redesigns. In that post, we briefly stated our overall goals:

jQuery UI is undergoing an API redesign which will slim down the size of the API in order to provide a more stable codebase that is easier to learn and use. We’ll be posting the proposed changes over the next few weeks in order to gather feedback from the community. Our goal is to support the old (current) and new (proposed) APIs simultaneously in 1.9 and then remove support for the old APIs in 2.0.

Now it’s three months later and two things are clear: 1) it’s taking more than a few weeks to post all of the proposed changes; and 2) we didn’t give enough information about the planned changes and the reasoning behind them.

The Past

When jQuery UI was first created, it was a combination of new and existing plugins. Pulling in existing, popular plugins was beneficial for everyone involved: jQuery UI was released earlier and with more plugins, the original authors’ hard work was publicly recognized and supported by the jQuery Project and the existing user base gained official support for the code they were using. Unfortunately, there was a downside to this approach. Because the existing plugins were written by different authors with different design principles and different coding styles, there wasn’t much consistency within jQuery UI. Between the 1.0 and 1.8 releases there were a few attempts to standardize various parts of the API, but there was never a coordinated effort large enough to make the necessary changes.

In addition to the inconsistencies between plugins, other problems started to appear over the past three and a half years. As users requested more and more features, the number of options, methods and events continued to grow. Over time, this led to what we have today, where something as simple as a draggable element has almost 30 options. On one hand, it’s impressive that so many various use cases can be handled, often with the use of just one or two of these options. On the other hand, finding the right one or two options to use can be a daunting task, especially for new users.

The Present

Recognizing the existing problems, we approached the 1.8 release differently. We defined a new process for building plugins that focuses on simplified APIs that are easy to extend. With the success of the 1.8 release, especially the simplicity and flexibility of the Autocomplete widget, we were convinced that our new process was working. Having a new process and new standards, we decided to go back and redesign all of our existing plugins with the same design process. In October, the jQuery UI team got together in Boston to do a first pass at redesigning all of the existing plugins. A few weeks later we started posting the proposed changes to gather feedback from the community. We’re still working through some of the details for specific plugins.

Our goal is to have a completely refreshed project with the 2.0 release. We will have a much simpler API, better stability, full documentation and a full test suite for every plugin. However, getting there will require a lot of backward-incompatible changes. We’re aware of how painful that can be and we are doing everything we can to reduce the pain of upgrading. Specifically, we’re doing the following while implementing the new API:

• Ensuring we have a full test suite for the 2.0 API
• Creating a separate test suite for the 1.8 API
• Re-implementing any deprecated functionality on top of the new functionality
• Defaulting to the 1.8 API in cases where the old and new APIs cannot live side-by-side

This approach has several benefits, with one of the most important being that upgrading to 1.9 should not break any existing pages. In fact, the 1.9 release will have better support of the 1.8 API than any 1.8.x release. As plugins are refactored for 1.9, many bugs present in 1.8.x will be fixed and some of the fixes will not be easily ported to the 1.8 branch. Because the support for the 1.8 API in the 1.9 release is actually new code built on top of the 2.0 API, it benefits from these bug fixes. The addition of a full test suite for the 1.8 API ensures that these bugs are actually fixed in both APIs.

Defaulting to 100% support of the 1.8 API is great for upgrading to 1.9, but it doesn’t provide a way to determine if you’re ready to upgrade to only using the 2.0 API. In order to deal with this, we’ve added a new flag, jQuery.uiBackCompat. If you load jQuery, then set jQuery.uiBackCompat = false, then load jQuery UI, none of the 1.8 API will be loaded. This will result in only having the 2.0 API available and will allow you to test your pages for compatibility with the new API and provide confidence that you will be ready to upgrade to 2.0 when it is released.

The Future

When jQuery UI 2.0 is released, we will no longer support the 1.8 API. However, the 1.8 API compatibility layer from 1.9 should continue to work; it will just not be included in the 2.0 release and will no longer be officially supported. All new plugins will go through the new design process so large API changes like this should not occur again. Once the existing plugins have been updated to our new standards, we should be able to move the project forward much faster than we’ve previously been able to.

It’s worth mentioning that only widgets, utilities and effects are being refactored in 1.9. All interactions are going to be rewritten for 2.0 so they will be undergoing a different implementation process. As a user of jQuery UI, there shouldn’t be much perceived difference between the widget refactors and the interaction rewrites other than the release date.

We know that no one looks forward to refactoring existing code to work with API changes, and we’re working to make sure the transition process will be clear and simple.  We hope that you, our users, understand that we need take this opportunity to refine jQuery UI to make it more robust, extensible, and maintainable in the long term.

Continuing with the API redesign, we have some changes planned for the Tabs widget. We know that API changes like this are not without cost to our users, so we’d like to make it clear that except where specifically noted, jQuery UI Tabs in 1.9 will support the 1.8 API as well, and the deprecated APIs will not be removed until jQuery UI 2.0.

API Redesign

Remove rotation.
The rotate method will be removed as it is not very common and has always been implemented as a built-in extension anyway. This will actually be removed, not just deprecated in 1.9 since it has always existed as an extension. Christopher McCulloh has an enhanced rotation extension based on the original code.

Overhaul ajax tabs
The ajaxOptions and cache options are being removed in favor of a new event: beforeload. The beforeload event will receive a jqXHR object and the settings object that will be passed to jQuery.ajax(). ajaxOptions is replaced by modifying the settings passed to beforeload and caching can be implemented by calling event.preventDefault() to prevent the ajax call and jump straight to showing the tab. We will also be keeping the href attribute unmodified and storing the panel id in the aria-controls attribute. The aria-controls attribute will be set for all tabs, regardless of whether they are local or remote. This will remove the need for the url method, which is also being removed. It will be possible to pre-define a value in the aria-controls value for remote tabs, removing the need to specify the location in the title attribute (which is also being removed). The abort method will be removed since the jqXHR object will be directly accessible and you can therefore abort the ajax call directly. Another benefit of the beforeload event is when paired with the existing load event, you can create custom loading functionality; as such we are removing the spinner option.

Selected vs. active
In order to improve consistency within the jQuery UI suite, select/selected will be renamed to activate/active across the board. What this means for tabs is that the selected option will be renamed to active, the select event will be renamed to beforeactivate, and the show event will be renamed to activate. The beforeactivate and activate options will include references to the tab and content panel for the old and new tabs, similar to accordion. In addition, the select method will be removed in favor of the setting the active option. Lastly, the deselectable option will be removed in 1.9 since it was deprecated in 1.8.

Remove templating
All options related to templating are being removed. The templating in tabs is a one-off implementation and creates an inconsistency with the rest of jQuery UI. This change includes the removal of the idPrefix, tabTemplate, and panelTemplate options.

Adding and removing tabs
The add and remove methods will be removed in favor of a new refresh method. This is consistent with how new plugins are updated after initialization. Removing these methods also means that the add and remove events are being removed.

Enabling and Disabling tabs
Tabs will properly support disabling individual tabs or the entire tab set. A boolean can be used to disable the entire set or an array of indices can be provided to disable individual tabs. In addition, the enable and disable events will be removed for consistency with other widgets.

Remove length method
The length method will be removed as it doesn’t serve much purpose and can easily be calculated by counting the number of list items.

Remove cookie option
The cookie option will be removed as cookie support is not core to the plugin. Cross-page state management should be easy, but not be built-in.

Design changes still in flux
There are a few things that we still haven’t fully worked out. We plan on replacing the fx option with show and hide options for consistency with other widgets, but are still working through an open issue of how to support effects across plugins. We would also like to remove the load method but we need to verify that it can be built as an extension. Until we get into the new implementation, we won’t know if this is possible; if it’s not, the load method will remain in the plugin.

Feedback

We’d love to hear your feedback on these changes. We want to make sure we address any issues the community may have before we finalize and implement these changes. If you have any feedback, please post it on the related forum post. Thanks.