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
Comments
Would be happy to mentor
This is a good proposal.
I think we could do some refining, but ensuring that Drupal, including important contributed modules are accessible to all is an important goal of the community.
It was decided last summer that we would target Drupal accessibility efforts at international standards, and not at country specific standards. I think this project would be a good move in the right direction, adding to the work that has already been completed by so many dedicated contributors.
I would be happy to discuss this proposal in more detail to help to refine it and would love to mentor you through the process.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Exciting
I agree. This looks like a great plan. I'm also glad to help discuss or refine. Last year we had a series of phone conference calls and Skype calls to do planning for Drupal 7 accessibility. I'd be glad to help arrange that again to get a group of people together who could help give advice.
My one suggestion is that you target Drupal 8 instead of Drupal 7. At this point, Drupal 7 is past the code "freeze" where feature changes are allowed. I know you had mentioned making an installation profile, but there are many parts of core that cannot be easily changed with an installation profile and can only be changed by making your own distribution of Drupal. The problem with a distribution is that so many fewer people end up using that. Instead I think you are right to target Drupal core. Ultimately improving core will have a much larger impact. But version-wise that would be Drupal 8 core.
Let me know if you have any questions about that. Thanks for your interest and your proposal. This is a very supportive community and I look forward to collaborating!
-Brandon
www.pixotech.com
Actually its is very possible
Actually its is very possible to do this in Drupal 7, given that no GSoC project should focus on changing core unless its truly necessary. I believe creating a module which works on top of core, should be more favourable - just to keep moving forward.
Contrib versus Core
@Bojhan makes a good point. A contrib module for Drupal 7 accessibility would be great. It could make improvements that some sites would use to be accessible by installing the module. It could also demonstrate some concepts that could be considered for Drupal 8 core.
There are certain changes, such as Form API changes, to core that cannot easily be made in contrib. There are no hooks that allow you to change certain behavior, such as form pre-rendering and form building. So some changes need to (thoughtfully) continue in core for Drupal 8. And ultimately we need the core product to comply with W3C standards such as WCAG and ATAG.
So for a summer/GSoC project, working on a contrib accessibility module or accessible sub-themes of core themes might be the best.
www.pixotech.com
accessible module reorganized
I reorganizedthe accessible helper module some into sub parts because of a patch kat3 made that confused me about how I originally structured it. I'm about to check it in to cvs so it should show up Friday. It looks like the accessible_content module has come a long way and I'm also looking at overlap with that module.
I can see some of the Drupal for All proposal fitting into the accessible helper module. If this is the case let me know so I can add you as a maintainer.
Acessible Helper module still doesn't have a lot of functionality, but is restructured as such:
==============
accessible_api
General toolset including guidelines data, site accessibility preferences,
and functions other modules may build on.
to drupal authoring contexts.
e.g. should content be positioned off screen left, top, or right.
==============
accessible_fix
Accomodate and fix accessiblilty deficiencies
in core and contributed module. Works on a case by case basis with hooks like
hook_form_alter to modify other modules forms and markup. As a rule, these
are either stop gap measures until real fixes are made in modules or when
accessibility implementation is unclear or preference based.
===============
accessible_help
Adds contexttual accessibility help for content authors.
===============
examples
www.johnbarclay.com
Thanks for the info. I'll
Thanks for the info. I'll start researching and planning on how I'm going to implement my goals next week. What parts of my proposal do you think would fit well with the Acessible Helper module?
Drupal for All work that could go in accessible_fix module
Working in core and other modules is by far a priority, but when patches are not accepted, the accessible_fix module would be a good place for the form, theme, etc alter/overrides.
I think any changes that don't get into core or other contributed modules will work in the accessible helper modules, particularly accessible_fix. Its designed for theme and module alterations for accessibility that are missing in other drupal code.
I made a push on the d7 version yesterday. The code is not well documented and not functional, but the ui is there for a couple of use cases. It should give you an idea of where its going, although the video walkthrough might be more useful.
Let me know if you want CVS access.
The current code is at: http://drupal.org/node/804084
A quick walkthough is at: http://blip.tv/file/3647172
www.johnbarclay.com
The Accessible Content module
The Accessible Content module might also be a good place to look if you are interested in the actual real-time assessment against guidelines. The area I see your project overlap a bit with the module is it's WYSIWYG integration module which specifically adds a TinyMCE plugin for checking the accessibility of content.
Other Contributed Modules
Just wanted to add a link to the page of Contributed modules to help with accessibility, mostly to make it easier to find in Google.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide