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.
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:
- 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.
- 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.
- 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.
- 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?