Here at CSU Monterey Bay we have a mandate from our Chancellor's office that all web content be accessible by 2010. This date is fast approaching, but we are moving towards a model where we automatically approve content for accessibility before it goes out to the web.
Our approach is two-fold: first, we are working on a flexible PHP library called QUAIL (QUAIL Accessibility Information Library) that uses the Open Accessibility Tests suite plus custom-built guidelines (WCAG, 508, etc); second, we are writing a small Drupal module that provides integration between QUAIL and the Drupal publishing workflow.
There's a demo up at http://php.csumb.edu/projects/quail, where you can post a story node and see how it would look to an end user. We are only running two tests on there right now - images with no alt text and suspicious link text - but I'll have the rest of the tests on by next week. There's more information available at the QUAIL project page at http://code.google.com/p/quail-lib/
While all the accessibility tests are done, we are still considering the entire project alpha right now, and the module is just a whisp of a thing, but we'll get it contributed to the greater community by July.
Any thoughts? What would you like to see in an accessibility module for Drupal?
Comments
Drupal accessibility Module
I think a good drupal accessibility modules would be one or more modules:
- a general accessibility preferences api that all the modules could leverage (see below)
- filtering, testing and validation module
- accessible editor(s) that worked with wysiswyg api/module
- accomodation module, to sidestep unresolved accessibility issues in existing modules when possible. (http://drupal.org/project/accessible)
- accessible help http://drupal.org/node/369477
An api that let admins set their accessibility preferences. Admin page might look like:
Accessibility Preferences:
Please note that some themes, modules, and drupal core itself may not care about these preferences. Selecting them does not guarantee anything.
Rulesets and Guidelines Requirements
[] WCAG 2.0
[] WAI-ARIA
Ala Cart Requirements
[] header heirarchy
[] alt tags
[] headings above ul and ol lists
[] labels for all form elements
[] aria roles
[] ...
Authoring
[] allow authors to override accessibilty filters and validation
[] allow authors to select thier editor
Hidden Content
[] offscreen left
[] offscreen right
[] hidden
General
[] allow users to opt of of accessible content (this may give them access to drop and drag, wysiwyg editors, etc.)
www.johnbarclay.com
Some of this already exists
Some of these ideas already exist in the Accessible module [http://drupal.org/project/accessible] - and once this gets up and running I think that a discussion about the future of both these projects would be a good idea.
The nice thing about the OAC tests is that they are decoupled from the guidelines, so yes, we can build an admin UI where someone can select either an entire guideline to follow, or build one that would only really apply to their site. Most of this depends on my finishing the QUAIL library to allow different data sources for translations and guideline building than just PHP arrays.
All of those Ala carte options you mentioned are already part of Quail's 274 accessibility tests and yes, folks would be allowed to add them (and I think per-content type would be nice as well).
Quail Sounds Great
Thanks to the link to the QUAIL Accessibility Library. AChecker Open Accessibility Tests sound good. Do you have any plans to integrate Plain Language testng. I know there are tools like the clarity rating calculator, but don't see this being available as an API.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Good idea
I know plain language is a requirement for many guidelines, and QUAIL right now "tests" for it by saying if a document has more than three words then it flags it as a "suggestion" - i.e. the user would see something like "Please check that your document's writing is clear" - that's one of those things that I think will never really be 100% accurate with automated testing.
The big thing right now to go forward with the rest of QUAIL's service layers like reporting and guideline buildilng, then we can revisit some of the tests to further refine them.
plain language resources
The suggestion could include a link to an external resource such as PlainTrain (http://www.web.net/~plain/PlainTrain/Digest.html) to help users better understand what the suggestion means.
Other references
This is the best one I've seen - http://www.plainenglish.co.uk/
A larger movement - http://www.plainlanguagenetwork.org/
The USA government had a good one too - http://www.plainlanguage.gov/
But it doesn't seem to be up right now, so there's always - http://web.archive.org/web/*/http://www.plainlanguage.gov/
The Wikipedia article is in dispute - http://en.wikipedia.org/wiki/Plain_language
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I Think PlainLanguage.gov became these...
Mike, we have two great sites dedicated to excellence in government Web communications. I think one or both of them evolved from plainlanguage.gov, so you might find that information in either or both of these places:
For example, on Usability.gov, the page on Writing for the Web gives advice that, if not "Rules for Plain Language" in the strictest sense, at least leads to the same destination.
Thanks for these links
Good to have these additional references.
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Admin will be able to customize error messages
Correct; however, the module will allow admin to customize error messages for each failed test or suggestion, so they will be able to link to whatever resource they would like.
I'm very interested in the
I'm very interested in the development of this module. Keep Cookin!
Great Projects
QUAIL and the Drupal module both sound like great projects. I work at Michigan State University, and we have a similar initiative to make all web content is accessible. I've recently been looking for an open source automated checker library, preferably in php, and quail should do the trick. Having this integrated into drupal would be a bonus.
Another good use for QUAIL
We are also looking into tying QUAIL together with something like ht://check or some other web crawler project to build a checker for existing content that might be outside a CMS. However, this approach is never very good for universities: by the time you notify the appropriate department that their content is not accessible, and they fix it, it's been months, and that content may have changed by then.
status of this project?
I'm wondering what the status of this project is and if it ever made it to a public release. I did a quick search but did not find it anywhere.
The library is still being worked on first
Before this module can really get off the ground, we're still focusing on the Quail Library itself. There's a whole Virtual Browser layer we're writing to check CSS accessibility as well.
The module itself is a pretty thin layer, just hooking into the node creation process and giving an admin interface to choose checks/guidelines and node types.
We're looking at a beta release of the library around August/Sept, so hopefully a dev version of the module can get out by October or November.