Future of accessibility checking discussion - QUAIL, Node Accessibility, Accessible Content, etc.

There has been a very good discussion going on in the issue queue of Accessible Content about the future of that module, as well as how it will relate to other initiatives to provide accessibility testing in Drupal. With the QUAIL project now at a stable state, I have been working on a complete rewrite of the Accessible Content module, but I would like to ensure we don't have duplicitous work going, and that any direction we go in is vetted by this community.

There are currently three big modules out there that deal with accessibility checking:

1. QUAIL API - A simple module to load QUAIL for developers.
2. Accessible Content - A general module for accessibility testing that is currently being upgraded (finally!) to D7.
3. Node Accessibility - Accessibility validation tool that does a lot of helpful reporting and provides statistics.

Since we are at the nexus of several changes, it would be a good idea to determine what functionality the community wants, and where those features should live. I don't think a single canonical module benefits the community. My own interest has always been content author experience, including WYSIWYG integration, and less so on reporting. That being said, reporting is another crucial feature that many organizations need. Here's what I'm thinking as a model that can prevent duplication and benefit the community through focused, concerted efforts:

1. QUAIL API be changed a bit to give site maintainers the ability to turn on and off tests, and to customize test results (Accessible Content does this using a new entity type, but I'm not wedded to that direction).
2. Accessible content be slimmed down to focus on WYSIWYG integration, content author experience, and automated testing on the client side.
3. Node Accessibility or another module become the place to get things like reporting and statistics (my only concern is the word "node" now that we are in an entity-filled world).
4. A new module be created to help themers make their sites accessible. There is a huge difference between theme developers and content creators, and they need different feedback mechanisms.
5. A new module also be created to integrate with automated testing. I have been using QUAIL in our own continuous integration environment, and if accessibility checking were part of the development workflow that would be a big win.

This approach would definitely take some work, but would also cut down on duplicitous efforts and ensure a more consistent experience for site maintainers.

Another idea might be to adopt the accessibility module and make it a nice package of sub modules that does everything.

Thoughts?