Just saw this accessibility evaluation of Recovery.gov by Jim Thatcher. Recovery.gov is the highest profile Drupal government site in North America and so it is an interesting view of how this government which is committed to accessibility & open government implements this great CMS.
Needless to say there are problems. I think most of them are tied to the theming & the content. The default core themes provide language settings I'm quite sure. The themers removed the language identification at the top of the page. They also produced a theme that really doesn't validate and isn't standards compliant. The default accessibility is quite a bit lower than what comes out of Drupal Core.
His description of the problems with In-Page Navigation does come back to Drupal core though. Not that it can't be overwritten in a custom theme, but it isn't set up properly by default. As I've stated here - http://drupal.org/node/364219 - we need to be providing more headings particularly for navigation links & menus. Any list item should be preceded by an h2 tag which describes it.
Having a best practice Skip Links in core will also make it easier for everyone to do it right the first time. Getting back to this issue here -> http://drupal.org/node/386462
The section on Text Alternatives is out of core, but does fall back to a few issues with the contrib modules and how alt text is handled there -> http://drupal.org/node/425494
We've done some work on the Contrast module, but generally this is something that falls on the designers to evaluate - http://drupal.org/node/134359 - nice to get reminded about it though. Particularly with an aging population of boomers approaching.
One of the neat bits about Recovery.gov is the timeline, unfortunately it is completely inaccessible. There's an accessible version of the timeline here using Yahoo's User Interface Library. Unfortunately, it's no where near as snappy. Drupal's Timeline module uses this SIMILE widget, and it would be nice if there was some work on making this library more accessible.
I also wonder in the Labeling Forms section if it is possible to provide customizable label titles that provide users with language that is geared to the specific use. In the implementation of a generic CMS, it is very difficult to be able to provide a generalized answer to how information will be used. Guess all we can do is provide a best guess and allow the developers to use the theme overwrite functions to add in more specific language.
Would be interested in other's impressions of Jim's critique.
Comments
About Recovery.gov and Accessibility
I appoligize for saying this but I really don't know Content Management Systems and I should!
That said, I have a question about your comments on In-Page navigation. There are two parts to that story (1) text that looks like a heading should be marked up as a heading and (2) it's improtant to have headings in front of each major section of a page to facilitate screen reader access to the content.
When authors are adding content do have they control over how a "heading" is styled or whether or not it is marked up as an html heading.
As far as Jim's Critique - I think it is great! There's a newer one on Data.gov in a different style, http://jimthatcher.com/data.htm.
Welcome aboard!
Welcome aboard, Jim!
If you would like to learn more about Drupal, the Austin Drupal Users Group meets from 6:30 to 8:45 p.m. tomorrow (Wednesday, May 27) at the Terrazas Branch of the Austin Public Library on East Cesar Chavez.
If you can't join us then, I would be happy to meet with you any time to share the experience of developing a site in Drupal. Contact me privately if you would like to set something up.
Drupal's Very Powerful & Flexible
Hi Jim,
Most of the work you wrote about regarding In-Page Navigation is tied to user generated content. The body of this generally isn't filtered for much more than a tool like Tidy to ensure that the HTML is valid. There are ways to add additional filters onto Drupal allow this to be more heavily processed. Projects like Open Calais certainly offer more opportunities to process user generated content. A module could certainly be developed to evaluate and perhaps even prompt users to add in appropriate headers if the text is too long and hasn't inserted the appropriate number of landmarks. Could also evaluate that user created content follow the appropriate heading's hierarchy. I don't see that as ever being something that makes it's way into the core code base though.
It's mostly in the menu's & lists generated by Drupal in the sidebar blocks that I've indicated that there is room for the CMS to improve.
I'd also like to see various WYSIWYG options disable the H1 option as I don't see any reason why a user should be allowed to add that. However, ultimately these are features that would be user configurable as there may be a user that wants to produce bad semantic data for some reason.
Thanks for the new link about the Data.gov evaluation. Hopefully we see some contributions from the Drupal community on The Apps for America Competition.
Mike
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
All HTML can be controlled
@JimThatcher - in Drupal we have complete control over headings via the theme templates. For example, on this page you will notice the sidebar blocks have h2 headings, which are inserted via theme template that controls the sidebar blocks.
For user entered content you can use heading tags, such as h2, h3, h4 etc. If you slide open the "Input Format" fieldset below the comment form (on this site) you will see all the HTML tags you can use. This is 100% configurable by site admins.
Drupal and accessibility
As mentioned above, it's all in the theming. I'd be the first to say that some of the newer high profile Drupal sites like recovery.gov make great use of the the theming ability of Drupal. They don't however seem to bring accessibility into the process like they should. While alt text and some aspects of the page content fall outside the control of the theme, skip links and most other aspects of accessible design do not. To my eye they've only design half a theme. They've made it pretty, but they haven't made it usable.
It's getting better (and Jim is helping)!
The efforts to make Drupal more accessible continue. There has been tremendous progress in Drupal 7 to ensure that it's easier to have an accessible site from the get-go. Mike, (mgifford), Everett Zufelt, and Brandon (brandonojc) have been three of the biggest contributors of patches to improve accessibility in core. And Jim Thatcher has chipped in a time or three to help review the results of their code and offer advice to steer us in the right direction.
Anybody who is interested in helping should mosey on over to the issue queue and skim the critical issues, look through the usability issues, and search all issues for "accessibility." If you have ideas and can help code, review code, or even only add new ideas, now is the time to make Drupal more accessible to everyone!
Code freeze for accessibility improvements is two months away -- November 15. A lot has already been achieved, but there is still time to make other great strides forward.