I thought that a task focused on evaluating Drupal's accessibility would offer good bang for the buck. Drupal already gets good marks in terms of accessibility, and a report providing more detail on that could be useful from a marketing standpoint. Also, an evaluation would likely turn up ways Drupal accessibility could be improved.

I'd love to hear any feedback or recommendations on this, especially any specifics I could include to better detail and focus how to perform the evaluation.

I'm also interested in additional (or alternative) ideas for accessibility related tasks. I'd be glad to mentor the tasks, if I have enough detail to get going. If someone who is more knowledgeable about accessibility is interested in mentoring the task instead, I'd be glad to turn it over.

Task description: According to Wikipedia, accessibility is "a general term used to describe the degree to which a system is usable by as many people as possible." Designing with web accessibility in mind entails understanding and designing for people with different types of disabilities. Evaluating Drupal from an accessibility perspective can help bring Drupal (and sites developed using it) to a wider audience.

This task entails researching accessibility, then evaluating Drupal and its core themes using accessibility guidelines. Both the end user and administrator interfaces should be evaluated. The deliverable for this task will consist of:

1. a report detailing the accessibility features of Drupal core (ie, What does Drupal get right?). This document will provide a starting point for any users concerned with accessibility who might be considering or evaluating Drupal.
2. a report detailing recommendations for how Drupal might be made more accessible (ie, What could Drupal do better?)

Resources:
* Choosing an Accessible CMS (an evaluation of the accessibility of various CMSs)
* AIR Judging Form (used to evaluate entries in a web accessibility design competition)
* Drupal Accessibility Modifications at the CWRL (a project-specific analysis of Drupal accessibility):
* Drupal's Accessibilty Group
* Understanding WCAG 2.0 (the Web Content Accessibility Guidelines provide a framework for evaluating a site's accessibility)

Primary contact: Matt V.

Comments

aclight’s picture

Status: Active » Needs work

This looks good to me. The only thing is that I would be a bit more specific about how the student should submit the report. Should it be a document attached to the issue (and if so, what format), or a d.o handbook page, or something else?

henrrrik’s picture

Maybe the evaluation can be limited to the Garland theme instead of all core themes? Spending time on the old table-based themes seems wasteful.

wmostrey’s picture

Henrrrik, if you think that the old table-based core themes are not even worth evaluating, this would be an even strong signal to remove them from core. I think this evaluation is a really good idea.

I don't think this should be made into a handbook page but an attached document.

aclight’s picture

I think it would be great if the student would be requested to post the findings somewhere else than just as a document in whatever issue on d.o gets made for this task for two reasons:
1. It's more likely that something good will happen from the findings if they are more widely publicized.
2. One of the judging criteria for the GHOP program as far as picking the best student goes is community involvement. The more interaction the student has with the community (including issue queues, groups, etc.) the better. Your references includes a link to a g.d.o accessibility group, so I would suggest that the report created by this task also be posted there so the student can get more feedback from accessibility experts.

I'm a little worried about the scope of this task. You don't specifically define accessibility, and there are a lot of things that go into "accessibility" including browser compatibility, JS vs. JS disabled functionality, color schemes (ie. how would the site look to a color blind user), screen reader use, etc. Looking at all of these items for all of the core themes might be too large of a task. I would recommend including a few areas that the student should focus on with regards to accessibility, but state that other areas of judging accessibility are welcome.

With regards to screen readers, I don't think we can expect most students to be able to evaluate this aspect, since as far as I know they aren't free and one would need to be an experienced user of a screen reader to really be able to evaluate how a site works with one. So unless it's easier for a "lay" person to evaluate how a site works in a screen reader than I am aware, I would specifically mention that doing so is NOT part of this task.

Matt V.’s picture

Thanks for all the feedback! I'll work on revising the task, to take the ideas into account.

mgifford’s picture

Interested in knowing where this is headed now that GHOP is over.

Also, the V6 AIR Judging form has been replaced with version 7:
http://www.knowbility.org/content/common/AIR-JudgingFormV7-20084.xls

Particularly useful since WCAG 2.0 is finalized now.

Mike

Matt V.’s picture

mgifford,

I don't know of anyone working on this kind of evaluation now. However, if expanded, it might make a good project for the 2009 Summer of Code.

mgifford’s picture

So I how do we get someone keen on doing this? Can anyone just post an idea here?

http://drupal.org/google-summer-of-code/2008/ideas-list

nfreear’s picture

Hi, This is a great idea.

A few comments regarding your screen reader concerns, "aclight" - I hope you don't mind ;)

  1. Some of the widely used screen readers have a trial period/demo mode. JAWS has a 30-40 minute demo mode, http://www.freedomscientific.com/fs_downloads/jaws.asp
  2. There are some free options - not all these are widely used by the blind yet, but they should give a developer a good idea of the issues.
  3. There are some browser extensions that can help developers:

I hope this helps.

Nick

--
Web Developer. Open University. Accessibility & standards.

mgifford’s picture

Also, given the complexity of accessibility issues, always good to point people back to the group:
http://groups.drupal.org/accessibility

I also wanted to put in a plug for folks to help clean up the remaining accessibility issues here that can hopefully be addressed for D7:
http://drupal.org/node/364629

mgifford’s picture

Issue tags: +Accessibility

adding accessibility tag

wmostrey’s picture

Status: Needs work » Closed (fixed)

This has happened for Drupal 7.