Yesterday I attended Accessibility Camp Toronto. The Camp was an (un)conference style event, with participants offering topics for discussion at the beginning of the day, which were then quickly scheduled by the event organizers.

I proposed a discussion on Software Accessibility Product Management, in which I used my work as the Drupal 7 Core Accessibility Maintainer (accessibility product manager) as an example. I was happy to be joined by a large number of participants, including Colin Clark, the Technical Lead for the Fluid Project.

Notes

The following are the notes that I sketched out on the bus ride to Toronto.

Personas

Managing a software project is primarily about working with people and connecting them with the resources (tools, training, other people, etc.) that they need to be successful in their roles. The following set of roles are the primary categories of people who interact in the Drupal community. Clearly most people overlap several categories.

- Core developers (those building the CMS
- Other developers (those building extensions and sites)
- Designers and Themers (those designing UIs and implementing designs)
- Administrators (those responsible for site maintenance)
- Authors / contributors (those creating content, including documentation)
- Consumers (those consuming content)

The following lists are questions that we must answer to ensure that each role is enabled for success.

Core

Core developers are responsible for maintaining and enhancing the underlying logic, features, and APIs of the product.

- Do APIs provide adequate semantic information?
- Are all accessibility features of markup languages, and extensions like WAI-ARIA supported
- Can markup be easily altered or overridden?
- Can scripts and styles be easily altered or overridden?
- Is accessibility by default a priority?
- Is there an accessibility policy?

Other developers

Other developers build contributed modules, and custom modules to enhance the functionality of Core.

- Are APIs easy to understand and use?
- Is adequate API / theme documentation available?
- Is information available about known / common accessibility features and failures?
- Is there a supportive community with accessibility knowledge?

Designers and Themers

Designers create user interfaces, themers implement design with markup and style.

- Are there style guide resources to lead down the path of accessible design?
- Are there well document examples of highly accessible designs and themes?
- Is adequate API / theme documentation available?

Administrators

Administrators configure sites, moderate content, reposition widgets (blocks), and enable / disable site features.

- Are extra steps required to 'configure' a site to be accessible?
- Are poorly accessible features enabled by default?
- Is it easy to enable features that cause accessibility barriers?
- Is it easy to enable features that remove accessibility barriers?

Authors

Authors contribute content (articles, forum posts, product descriptions, comments, etc.) to the site.

- Are authoring tools accessible?
- Do authoring tools generate valid markup?
- Do authoring tools generate semantic markup?
- Do authoring tools expose accessibility features (table headers, alt text) in a fashion that is easy to understand and use?
- Are features available to provide an automated evaluation of content accessibility?
- Is training available on how to use sets of tools to create accesible content?

Consumers

Content consumers are visitors who come to a site to consume content (read an article), or perform a task (update mailing address, purchase product).

- Are pages and content perceivable?
- Are pages and content understandable?
- Are pages and content operable?
- Are pages and content robust?
- Is there an easily discoverable accessible feedback mechanism to report problems with using the site?