DrupalCon Accessibility BoF Notes

At DrupalCon San Francisco 2010 we held an Accessibility BoF (Birds of a Feather) on Monday at 11:00AM in Room 262. I've included notes and links from our discussion. If you have any additions or corrections, please post a reply.
 

Attendees

• Mike Gifford, mgifford from OpenConcept.ca
• Owen Barton, grugnog
• Brandon Bowersox, brandonojc from ojctech.com
• Matthew Mattingly, mdmattin from UMass Amherst
• Kathy Kahl, daisyk from DAISY.org
• Caroline Boyden, cboyden from UC Berkeley
• Dan Chaney, dcrelabs
• Scott Worthington, seworthi from Estrella Mountain Community College
• Luke Withrow, lwithrow
• Kevin O'Brien, nowarninglabel, San Francisco State University
• Kevin Miller, kevee, California State University, Monterey Bay
• Everett Zufelt, aka Everett Zufelt, who gave the Core Developer Summit accessibility presentation
• John Foliot, Standford University Online Accessibility Program
• Charles Belov, aka charles_belov, San Francisco Municipal Transportation Agency
• Kate Lynch, kat3_drx, Drexel University Libraries
• Ruben
• Greg Pool

If anyone has additional contact info or corrections, please post a comment.

Theme Switching

Is theme switching a good accessibility approach? Kate suggested checking out glaucoma.org for an example of a site that gives lots of switches at the top for layout, text size, and contrast. Everett and others suggested that the approach of having a separate theme can cause problems if it is not maintained over time. Also, "how many toggles can you really add for every different user preference?" The idea of having a "separate but equal" theme or user experience has its downsides. In general, everyone agreed that making the primary theme more accessible is the ideal long-term solution.

YouTube Captions

Google now provides automation captioning for YouTube videos. But they admit that the speech recognition technology is not perfect (unless you speak exact American English in a small, quiet room with a microphone close to you). CaptionTube was one tool suggested for making captioning more easy-to-use as an online tool without special software. The group discussed difficulties with getting content contributors (such as faculty) to provide captions.

Caption support in Drupal's video and media modules

"If you need a Drupal module to support videos with captioning or transcripts, what do you use?" There are lots of small but significant accessibility problems with contributed modules on drupal.org. And there is no way to know which module is best. One suggestion was to use the Media module and to add fields to your media content -- you could add a field for a link to the text transcript, for example. There are 4 or 5 video player modules on drupal.org including Media module and Flowplayer. Owen suggests that we simply open an issue in the issue queue and submit a patch for each. Kevin (kevee) said that Quail briefly had a test to check whether a video had a transcript, but Google removed that API.

When you find an accessibility problem

There are three important things to do when you find an accessibility problem in drupal core or contributed modules:

1. Go into the issue queue and start a new issue if there isn't one already. For example, "please provide caption support for this module." Even if you cannot code the fix, you can provide an overview of what is needed and why.
2. Speak up on groups.drupal.org to raise awareness and start a conversation. If you don't know where to post an issue or how to use the issue queue, you can start with a conversation and the group can help.
3. Tag your issue with accessibility.

Quail and the Accessible Content module

Kevin (kevee), the author of the Accessible Content module, described the impetus. He had projects with hundreds of contributors who didn't know HTML and they were creating content without knowing how to make it accessible. Hence they created Quail, an open source (GPL) PHP library for checking adherence to accessibility standards.

The module uses hundreds of the accessibility tests provided by Quail. Each test is a node in the Drupal site so that it's easy to customize the tests. For example, you could change the name or description of a test so it will be more helpful to end-users who run the test and need to learn what they did wrong and how to fix their content. You can also configure the levels of checks and severity used for each content type in the Drupal site. For example, you can require that Press Releases cannot be posted if they fail any severe test. It allows you to export settings and import those into another site. It has checks for tables and all sorts of content-level accessibility issues. The biggest issue now is providing automated color contrast checks and checks for "display: none" CSS.

The Quail website has a list of all the supported tests including which tests align with Section 508 and W3C WCAG 1.0 and 2.0.

Related Tools

The group discussed some of the other tools and libraries such a AChecker and a new PHP tool. We also discussed whether SimpleTest could be used to check parts of core and contributed modules or themes for accessibility. In addition, Owen mentioned that there is a module called Content Quality API that checks for W3C standards, SEO, and we could work with them on adding accessibility checks to that module.

A Drupal Accessibility Statement

Mike suggested that we need an accessibility statement for Drupal 7 and 8. Everett suggested that we make an alias for the URL drupal.org/accessibility to point to all this. An accessibility statement could live in the Handbook near the other drupal community principles about community participation and inclusiveness.

John suggested we create a reference for which add-on modules are good for accessibility. The group discussed how we could assess accessibility, and how we could encourage module contributors to want to improve accessibility. We identified 3 important pieces:

1. First, how can site builders find the most accessible contrib modules when they are picking modules to use?
2. Second, how can module creators learn what to do?
3. Third, how can content authors get guidance about how to build and structure their content?

We talked about user-friendly educational materials. Opera and the Web Standards Project (aka WaSP) apparently have a good curriculum and developers network. Also the Consortium on Disability Information (CoDI) is another resource for bloggers and webmasters. Kate reminded us to not dwell solely on visual impairments but to remember all the cognitive and other disabilities of web users.

Testing by Real People

The group discussed how to find human evaluators to conduct real accessibility checks on websites and on Drupal core and contrib. A number of people suggested how to find good groups of testers. Everett said that it's important to find the real users who are well-connected in the disability community and then make sure you pay them well for their time (such as $50 for a testing session). Kevin also said the San Francisco State University Access Team will be here on Thursday for a day of training and learning. Many university accessibility teams are a good place to start to find testers.

Mike said that Bojhan and others had discussed getting an accessibility testing session together in order to have an official evaluation of Drupal core. Kate has recently conducted testing and has just released video which she showed in her presentation. Moodle apparently received funding in order to bring in a team to conduct accessibility testing.

Next Steps

A number of threads emerged in our conversation as efforts that a critical mass of the group wanted to pursue:

• Conducting accessibility testing of Drupal and releasing our results to the community, just like the Usability Testing in 2008 and 2009 which helped capture attention and focus efforts of the whole Drupal community around usability. There was talk of ATI funding, help from SF State University and the CSU campuses. Interested folks included: Kevin, Kate, Mike, Brandon (anyone else please chime in).
• Creating an Accessibility Page and Statement for Drupal. Interested folks included: Everett, Owen, Mike (anyone else please chime in).
• Creating a voluntary "pledge" that module authors can add to their module, much like #D7CX. This would be a pledge for the module to support accessibility. Interested folks included: Owen, Brandon (anyone else please chime in).
• And the next BoF at DrupalCon is Wednesday. Watch the board for details.