Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough

Update to the State of Drupal 7 Accessibility

Parent Feed: 

Introduction

I have been encouraged by the increased participation in the Drupal 7 accessibility issue queue in the past few weeks. There are still a number of outstanding issues that are fundamental to improving the accessibility of Drupal 7. Some of these issues can be dealt with after code freeze, others need to be dealt with before.

I believe that Drupal accessibility has to be adopted and fostered at the grassroots level.  Hopefully after code freeze some additional accessibility documentation can be added to Drupal.org and the documentation that is currently on the site can be reordered to make it more useful.  I believe that clear and thorough documentation will lower the barrier for entry into the Drupal accessibility arena, making it easier for community members to get involved who currently don't know where to start.

Ongoing Accessibility Challenges

I believe that one of the problems that will continue to persist, even with the best efforts of the Drupal accessibility community, is that accessibility, like usability, CSS, PHP, and SQL, is a specific skill set.  Unfortunately, at this time, there are far more community members who possess these other skills than the skills related to accessibility.  I imagine that increased documentation and community involvement of those who do possess accessibility skills will help this situation, but also imagine that without the adoption of some form of minimal accessibility standard for Drupal that accessibility will continue to lag behind.

Perhaps the best approach to take, given the current Drupal accessibility landscape, is for the Drupal accessibility community to continue to do its best to educate and assist with accessibility, until there is a threshold level of accessibility awareness within the broader community.  At that time, I believe that it will be useful, and achievable, to enforce a minimal accessibility requirement on all patches committed to core.  I also believe that it would be useful for community members who are interested in accessibility to raise awareness by asking the question: "How has accessibility been considered for this patch", on any issues involving user interface components.  I am happy to make myself available to anyone who has questions about improving the accessibility of core components at [email protected].

Current Accessibility Needs

As far as getting as much accessibility into Drupal 7 core as possible, I want to start by thanking the community, for the support that we have received thus far.

The following, in no particular order, are needs that I have from the broader community to assist me in using my time as efficiently as possible between now and September 1, and even after September 1, so that as much accessibility improvement as possible can be realized.

1. It would be really helpful if when community members notice an accessibility issue that they believe can be dealt with after code freeze that they would add a quick comment.  This will help me to better prioritize issues.

2. There are several areas that need work, that I believe will be required before code freeze, A list of the areas, and an idea of resources that would be helpful to me, are listed below, in no particular order.

a. Autocomplete - A brief walkthrough of how the JS events are currently handled so that I can figure out what is causing "undefined" often to be returned for screen-reader users would be useful.  I imagine that we will not get ARIA support for autocomplete into Drupal 7, but this may be able to be handled with a contributed module.

b. Table-drag - At the very least some decisions need to be made about where to place an option to disable drag, and what the scope and persistence level of that option will be. It would also be helpful if someone familiar with the code could work with me to roll this patch, as it would save me the time of having to learn how this component works on the code level.

c. Identifying "active" menu item links - I have read through menu_local_tasks() a few times, and am still not certain about which calls to theme('menu_item_link'), ...) are being called for active menu items.  It would be helpful if someone familiar with the coding of the menu system could help me to work through this so that I can role a patch for theme_local_task not providing context to screen-reader users.

d. Form element labeling - I am working through all form elements to identify problems with labels, there are currently a number of open issues about form element labeling.  My suggested approach is that * every * form element that supports a label (e.g. not button or fieldset) have a label generated, and that a new property be added to all of these elements "#show-label". If the "#show-label" option is false then the label will be styled with .element-invisible so that it does not appear on screen, but will still be accessible to screen-reader users.  Wondering if any community members have any thoughts about this approach.

e. Form validation - As I understand it, invalid form fields currently have their labels marked with the class "invalid".  I believe that the forms system needs to be modified so that more information is made available within the label for invalid form fields.  At the very least an icon, or other structural element that supports text, that indicates that the field is invalid.  I believe that this will require a change to how theme_element() currently deals with labeling.

f. Collapsible fieldsets - currently there is no information available to screen-reader users regarding the function of the links used to expand and collapse fieldsets.  There is a visual icon, but this is styled as a CSS background image, and cannot have an alt attribute set.  My recommendation is that the CSS image be included within the link as an img element, and that the JS switch the class, and alt attribute of the img where it is currently switching the background image.  I will need the assistance of someone familiar with the JS involved here to understand the functionality so that I can roll a patch for this issue.

Conclusion

Some important steps toward Drupal 7 accessibility have been achieved thus far, but there is still more work to be done between now and code freeze. I am hoping that the issues listed above, along with many other smaller issues, will be able to be adequately addressed between now and the release of Drupal 7 to ensure that it is a robustly accessible CMS. Not only will improvements to Drupal's accessibility mean a great deal to users with disabilities, but it will also mean more opportunity to use Drupal in government and with other organizations where accessibility is a must.

Original Post: 

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web