Overview: I propose to increase the accessibility of important Drupal interfaces for people with various impairments. Specifically, I want to modify Drupal 7's core themes, the WYSIWYG module's TinyMCE configuration options, and View's interface and output to be more accessible.
Description: Browsing the web can be a very laborious and tedious task for people with impairments. But it doesn't have to be. Specifications such as WCAG, ATAG, and ARIA exist to help content creators and software developers make the process of using the web much more efficient for the impaired. Since Drupal is so widely used, I think it's important for at least it's most basic features to easily comply with prominent accessibility specifications.
My proposal consists of four main tasks:
- Add an option for administrators to configure Drupal's core themes for ARIA Landmarks.
- Modify (or at least sub-theme) Drupal's core themes to reach some level of compliance with the WCAG 2.0 draft.
- Add an option to the WYSIWYG module's TinyMCE configuration to comply with the ATAG 2.0 draft.
- Modify the Views module's interface and output to comply with ATAG 2.0.
ARIA (Accessible Rich Internet Applications) Landmarks are important because they allow users to quickly skip to different sections of a page. On the other hand, if a page is using ARIA Landmarks it will not validate, so their use must be optional at the administrators discretion.
WCAG (Web Content Accessibility Guidelines) is a large specification that specifies three levels of compliance. So, I propose to modify (or sub-theme) Drupal's core themes to comply with WCAG 2.0 wherever applicable and feasible.
For this proposal, I'm going to scope ATAG (Authoring Tool Accessibility Guidelines) compliance to the WYSIWYG module's TinyMCE configuration options, and Views. TinyMCE can be configured to comply with ATAG (see "TinyMCE:Accessibility" at moxiecode). Since Views is a very complex module, and I'm not exactly how much work needs to be done to bring it within full compliance of ATAG, I will skip specific parts of the specification if I find that major modifications would be required.
It may also be nice if there was some sort of “Accessible Installation Profile,” so if time permits, I may create one.
Timeline:
April 26 – May 24 – Do some light research on the specifications. Contact applicable module maintainers and contributors to discuss the best ways to carry out the tasks.
May 24 – May 31 – Add ARIA Landmark support to core themes.
May 31 – June 21 – Modify core themes for WCAG 2.0 compliance.
June 21 – June 28 - Add support for an accessible TinyMCE configuration.
June 28 – July 12 – Slack period, in case things don't go as planned.
July 12 – Mid-term evaluation.
July 12 – August 9 – Make Views output and interface ATAG 2.0 compliant.
August 9 – August 16 – Go over code, make sure it's well documented and easily understandable. Perhaps write some documentation for drupal.org to help theme developers make their themes accessible in Drupal, and create an installation profile.
Mentors:
None right now, any takers, suggestions, or advice?
Difficulty: Medium to Hard