Progress on accessibility module

kevee's picture

Here's what will (hopefully) be a weekly post on progress with the Accessibility module, including calls to the community to give feedback on sticky problems.

What's been done

  • The core accessibility module is working well, simpletest coverage is growing, and APIs for contributed
  • modules to add their own tests is done (documentation forthcoming).
  • The WYSIWYG module has been tested by a number of folks and works well. Check-as-you-type is on the way.
  • Content checking is "done" in that it's feature-complete and any bugs or feature requests are related to
  • the core Accessibility module. We just did an update to QUAIL that allows us to tag tests as related to
  • content or not, so we won't have false positives about things like skip-to-content links.
  • Same situation with the Theme accessibility module as the content module.
  • The 8.x branch's progress is slowed by upstream dependencies and a shifting API landscape in 8.x. I'm confident these will be overcome in the next month or so.
  • Documentation on the module is up on, and I just committed a lot of hook_help implementations to help folks set up accessibility checking on their site.

What needs to be discussed

The biggest challenge is captured in this issue, which has grown from a discussion of handling multiple errors thrown on a single element to really a broad discussion of the best and most accessibile UI for giving feedback to users when an error is found.

While developers can override the way the module does feedback to make it more consistent with their site, I think it's important that we give site builders a sane default with a few other options. Right now we:

  • Add a class to the element to give it a red/green/orange dashed border
  • Use a custom popover to show the error message of that test when the element is clicked.

This is terrible and I know it, it's not keyboard accessible and uses color. I cry every time I look at it. Here's a few options:

  1. Prepend the element with a link around either text or an image that is overlayed the target element. while also outlining the element. The image/link can provide keyboard accessibility and visually differentiate tests of different severities without using color alone.
  2. When the user clicks on the element they either:
    1. Open a modal (overlay?) with the error message.
    2. Open a popover that has appropriate ARIA roles.
    3. Link the user directly to the accessibility test page.

Looking forward to reading your thoughts!


Do you mind if I talk about

jessebeach's picture

Do you mind if I talk about this work at Drupal Gov Days?

Not at all! We've had lots of

kevee's picture

Not at all! We've had lots of interest from higher ed, but as more sectors know about it the momentum can only grow from there.

Web Developer, Cal State Monterey Bay

Hi Kevin, thank you very much

falcon03's picture

Hi Kevin,

thank you very much for working so hard on the module development. I'm really looking forward to give it a try. BTW, if I visit the project page I can't see any published release. Could you publish it, even if it is a dev version, please? I think that it could be easier for users to test the module by downloading it and installing it in a testing environment than by cloning the git repo, copying the files in the right place and, after that, enabling the module in their testing environment...

On a side note, will this module conflict with If so, could we solve the conflict by unpublishing/deleting the accessible module? It has been lying around for a while, but it has never been made in a stable version for D7... It hasn't even gotten any significant update recently!

Added release snapshot

kevee's picture

Thanks, I added a release.

This won't conflict with accessible as far as I know, that one has a different scope.

Web Developer, Cal State Monterey Bay


Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week