DrupalCon Accessibility BoF #2 Notes

After quick introductions, we chose 3 topics to focus on: first, the Accessibility Pledge idea; second, Drupal 8 planning; and third, the Accessibility Statement. Many of these ideas were discussed earlier, including at Accessibility BoF #1.

Attendees

• Mike Gifford, mgifford from OpenConcept.ca
• Everett Zufelt, who is the Drupal 7 Accessibility Maintainer and gave the Core Developer Summit accessibility presentation
• Brandon Bowersox, brandonojc from ojctech.com
• George Cassie, gcassie
• Annice
• Maya
• Chris Bosco, cbosco
• Kasia Wakarecy, kasiawaka
• Jennifer
• Erik Peterson, eporama
• Caroline Boyden, cboyden from UC Berkeley
• Liz MacDonald from California State University Monterey Bay
• Chas Belov, charles_belov from the San Francisco Municipal Transportation Agency
• Cousett Ruelas, cousett from St. Edward's University
• Cliff Tyllick, cliff, joined via Skype
• Michelle Ziegmann from UC Berkeley

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

1. Accessibility Pledge

Many people have suggested that we invite module and theme developers to make a commitment to accessibility. This would be similar to the #D7CX pledge, where project maintainers pledge to release a Drupal 7 version by a certain date. The name #D7AX (Accessible Experience) was suggested.

Discussion

What's in it for me as a module developer? For one thing, if there are 5 modules that provide similar features, if one of those is accessible it will stand above the crowd and get more use. Everett suggested that one difficulty with a pledge is that accessibility is not something that is "finished" by a certain date, like #D7CX. Caroline suggested that #D7AX would not be a "badge" that it is finished, but rather a commitment to work to maintain accessibility as it evolves. Brandon suggested that it is a pledge to be part of an "accessible Drupal ecosystem". Erik said that it would be similar to a security pledge, which signifies that module authors are eager to respond when they learn that their module is not secure.

Does the pledge signify adherence to any set of standards? Everett suggested we could create a short sub-set of WCAG standards to create a concise list of "Drupal Accessible Module Guidelines". Part of the pledge would be that module authors voluntarily meet those guidelines. Caroline said she has a short "Top Ten Tip" list for accessibility that she can distribute. Or the pledge may not be a statement of compliance with guidelines, but rather a "social contract" that "my Drupal module is committed to being accessible". Cliff suggested that it is a sign that the author is committed to improving their module whenever someone brings an issue to their attention. The pledge also should recognize that there are different "layers" of accessibility: front-end accessibility for site visitors, back-end accessibility for site builders, and the accessible creation of content and comments as all the authors and contributors add content.

How do we promote this? Mike suggested that we need to clearly define the hashtag pledge, and then we all need to speak out and ask module and theme developers to make this commitment. We discussed filing issues tagged as 'accessibility' in the issue queue, and then encouraging each other by posting '+1' on those issues, helping make sure they're posted in the right place, and suggesting ideal markup to improve accessibility.

How do we give constructive input to module authors? Kasia suggested that we start by reviewing the top 100 modules for accessibility and post issues in the queues. Caroline urged everyone to post constructive feedback with suggestions and not just complain. Everett says it is important to say what the problem is, who is affected (a builder, contributor or visitor), and what the markup is. If possible, show the current markup and the proposed new markup. If you're totally unclear of where or how to file an issue, start by posting a discussion on the Accessibility groups page.

Is this just for Drupal 7? Erik suggested that we take the D7 part out of the name and not target a specific version. Everett pointed out that the release of Drupal 7 might be a big change to take advantage of the timing to promote the issue.

Next Steps

Further discussion of the hashtag name can happen on the Accessibility groups page. Cliff offered to post an idea of a statement. Cousett offered to help with the statement as well.

2. Drupal 8 Planning

We had an ad-hoc strategy for Drupal 7 and we ended up getting a lot of good things done, but we could do a lot more if we're strategic for Drupal 8.

Discussion

What standards and levels of conformance? Everett had proposed levels of conformance and ways to assign severity to core bugs in his Core Developer Summit accessibility presentation. Basically, we need to decide what we are aiming for (such as WCAG 2.0 AA), make sure we provide decent documentation, and also make sure all markup generated in core can be themed by a themer or overridden with a template or hook.

ATAG compliance would be great, but the group agreed that because it is still a draft it would be a moving target. In addition, Section 508 has a new draft released but it will also change significantly before final adoption. Everett suggested that we not focus on any specific countries' guidelines but instead using international standards like WCAG and ATAG and then create a web page to map our national guidelines against the international standard.

Do we also need a VPAT statement? VPAT (voluntary product accessibility template) statements is one possible tool for stating Drupal's conformance with accessibility standards. Because this may be needed for some government organizations to adopt Drupal, it was suggested that we create a VPAT statement for Drupal 7 when it is released. Chas suggested we also promote this in the local government group.

How can we coordinated our work? Brandon proposed we have a monthly Skype call during Drupal 8 work to coordinate our activities. The group generally agreed that this would work if we published agendas in advance and had a regular time to meet.

Next Steps

Chas, Brandon, and Cousett were all interested in moving forward with this. We can start in the Accessibility group with proposals for what exact level of conformance we want to target and how to move from planning to implementation.

3. Accessibility Statement

We discussed a formal Accessibility Statement for the Drupal project and community, and what to put online at an alias such as drupal.org/accessibility in order to act as a "portal" for all the Drupal accessibility information.

Discussion

This relates to the VPAT discussion above. Governments want to see an accessibility statement, and some organizations require a statement before funding a project. Everett suggested that even if we haven't done everything perfect, we can acknowledge what we have done and also acknowledge our remaining accessibility weak spots. Having an honest statement will show that we are serious and give us long-term goals to work towards.

What are the key parts to include in the statement? Guidelines we are aiming for. Links to educational materials (if the materials are on other sites, we should not reinvent the wheel). A short and concise statement so people will really read it. Everett suggested an executive summary separated from the details. Mike already started a Wiki page to Create Drupal Accessibility Statements.

Next Steps

Cousett and Cliff both said they had developed accessibility statements and were willing to contribute to this. We can start with making edits and suggestions in the Wiki page mentioned above.