Accessible Content and QUAIL 2.0

After a few years hiatus from Accessible Content to pursue other things, the QUAIL project has moved on to version 2.0, and so too must the Accessible Content module.

QUAIL

First, some news about QUAIL. As you may have noticed on the QUAIL website, I've been working on a complete rewrite of QUAIL. Namely, the project is now a jQuery/Sizzle plugin, rather than a native PHP library. Originally, I had meant for the 2.0 version of the project to have both a PHP and JavaScript version that were kept in parallel; however, on a snow-bound train ride back from Drupalcon Denver, I realized that the JavaScript version was a better way to go. First, PHP had DOM performance issues, even with QueryPath, and second, in the old version of QUAIL the project was saddled with having to do crazy things like write CSS interpreters and investigave JavaScript parsing. The move to being a JavaScript project allows us to do more testing for JavaScript and AJAX accessibility, and in general is much faster.

As of today, QUAIL 2.0 is in beta, you can download the latest version (or beta tag) from it's new home on GitHub. There is also pretty good documentation available, as well as examples using Aloha editor and a dummy CMS.

There are already a ton of new tests I want to develop around ARIA specifically, but QUAIL has always been a project focused on helping content editors achieve accessibility within the CMS, so I'll wait until the core of QUAIL is done before stepping into that arena.

Future of the Accessible Content Module

With QUAIL starting to be put to bed, the obvious next step is integrating it with the best CMS in the world. This new version would take advantage of Drupal 7's entity system to solve previous issues surrounding flexible data models, as well as WYSIWYG integration. The following is a list of things I'd like to see this version do:

1. Improved test management - In the old version of the module, we stored tests as a separate node type. That was kinda broken and in general sucked. By making tests something that a user chose to install, and their own entity type, we can allow tests to be fiedable as well.
2. WYSIWYG Integration - Now that we run in the client side, integrating QUAIL with as many editors as possible is something I'm really interested in. While some of this is work that is not Drupal-specific, I'd like to see the module expose that work to the WYSIWYG module.
3. Inline reporting - Instead of only showing accessibility problems on the page while a user edits it, we can instead have a widget on the page that will highlight areas of the page that have accessibility issues. This can help not only content editors, but also themers as well.
4. Better reporting - Now that we can move tests to being their own entities, I think if users want reporting the best way to do that is with views and the Relation module to join a target entity with a test and then track number and type of erros in the relation entity itself. Relation is a deep rabbit hole, but if we can ship with some default views that will help some.

What do you think?

I'm starting a new 7.x branch of the Accessible Content module today, hopefully in the next few weeks it will be ready and I'll announce it here. Are there any other features you would like to see in the next version of the Accessible Content module?