Accessibility Critique of the 2010 Open Source CMS Report!

By:

on

December 14, 2010

Earlier this year we agreed to sponsor the IdealWare's 2010 report comparing popular open source content management systems, and we're glad to have done so! It is so important to have a review of different systems if only to encourage discussion & debate about software use in the non-profit sector.

Why Drupal 7 is Great

Earlier this week I boasted on the NOSI discussion list about Drupal 7's accessibility enhancements. I know how much more accessible it was than Drupal 6. I have also done some work to compare it with other popular CMS systems.  We've developed a frank accessibility statement, that outlines not just what the software does, but how we will work for a more inclusive community. There is an active accessibility community both online & in conference BoF (birds of a feather) sessions. 

We've addressed a great many accessibility challenges and done so in a way that is public so that other communities can draw on our experience. There are also people who are contributing leading edge approaches to managing accessibility. An organization looking to build an accessible site now should really be looking at adopting as much HTML5 as possible. Drupal 7 core is presently built on xHTML, but there are more accessible themes which allow more use of the still draft HTML5 & WAI-ARIA.

 

Approaches to Evaluation

Now it would be very important to know how the testing for this was done. Drupal's small core approach in some ways puts it at a disadvantage because out of the box without a few key contributed modules it really isn't all that pretty. From the discussion of the initial setup, some contributed modules are installed.

I may well have missed the abstract or metric that was used to discuss this. I remembered last year there was quite a lot of discussion about this report's security section. It's not easy sometimes to evaluate two products when they have different communities.  Drupal core still probably has more known accessibility issues than any of the other CMS's in the report, but that doesn't make it the least accessible, just the most scrutinized.

There are some things in the accessibility matrix I find a bit confusing. I really have no idea what "Order of standard nav bar and content items" has to do with accessibility. I've never heard that raised as a concern, but of course one would want to be able to modify that.

Finally, as far as the categorization goes although the largest, richest, visually impaired user of the Internet is Google, one can't simply lump SEO with accessibility. I'm sure the SEO folks are as concerned about this as accessibility experts are.

Section 508

Although I know this report was written for largely a USA audience, it's important to keep in mind that the WCAG 2.0 standard is a much better tool to help guide folks to making their sites universally accessible.  Although it is being revised, the USA law was written in 1998, back in the good old days of Internet Explorer 5. How much of your web experience has changed since you last used IE 5?

Now I know that a lot of organizations who get federal funding in the USA need to be Section 508 compliant, even if it is really out of date. However, even after the government updates it's standards, which should be out sometime 2011, software is International, so lets look to the WCAG rather than any governmental standard.

As I've outlined before in this blog, there are a number of Drupal themes for both Drupal 6 & 7 that have made enhancements for accessibility.  I don't know which have been evaluated specifically for the old Section 508, but I do think it's important to think more about moving towards ever improving a site's accessibility rather than simply looking back to meet an old guideline. 

Accessible Themes & Administration

Having a few core themes evaluated for accessibility is great, but the bulk of the output from any CMS isn't generally controlled by the theme.  Evaluating both the front-end and back-end for accessibility is important especially because increasingly they overlap. How many sites being built now have a section for comments or other forms of user interaction. Even simple search forms often pose accessibility challenges for some users, let alone forms like those required to download this report.

Implementing an accessible site is harder than just picking a good starting theme for the right CMS and going from there.  Any CMS can very easily be made quite inaccessible by choices made by developers & themers of the site.  Furthermore, the content generators need to understand how to generate accessible content. 

Accessibility Basics

Alt tags are of course a basic tool for both screen readers & search engines to understand what an image is trying to present to the reader. Drupal 6 core doesn't support image uploads, but there are a bunch of modules that do.  Drupal 7 now supports image uploads and alt text, but there are known accessibility problems with it.  These problems will probably be addressed by the Accessible Helper Module which will be working to improve upon what was brought into Drupal core.

Header tags are useful, but not as standard as they should be. Headers are used by screen reader users to navigate a web page.  If the headers aren't in place it makes it more difficult to contextualize content. Until WAI-ARIA/HTML5 are finalized and screen readers are effectively reading the markup, header tags are still the best way to easily find search boxes and indeed any group of data. 

As outlined and documented in the Drupal 6 to 7 theme migration notes, all lists of links such as menus, need to use a header.  For practical purposes though we really need to have a defined way to hide that header element so that it isn't displayed to sighted people who don't need the additional navigational context.  Adding a consistent way to present what content you want presented to the screen reader & what you want presented to sighted users is a huge advance which has been implemented in Drupal 7.

Challenge for 2011's Report

I am a bit baffled as to why Drupal 7 did so poorly in the evaluation, as are others. All core themes have been reviewed for accessibility, and it is a component of reviewing which themes will get into core. Although not perfect, and without having reviewed Joomla 1.6 or Plone, I honestly don't think that there is a more accessible open source CMS available.  However, in this report it stands out as the lowest of all four systems evaluated for it's accessibility.

Drupal 7's admin has been tested by screen reader & keyboard only users.  Considerable effort has been put into ensuring that people can install, configure & fully administer Drupal 7 sites.  Many of the enhancements that have been done to Drupal 7 core are going to be inherited with the modules that use that core functionality.  I don't know any other project that has a role for accessibility maintainer, or that has made accessibility issues a release blocker.

I haven't reworked the matrix yet, but really hope that in 2011 the report does more to assess the community, do evaluation with tools like WebAim's WAVE toolbar, and assess the activity of the community behind the software.  The process matters more than the claims made by any proponent of software. 

About The Author

Mike Gifford is the founder of OpenConcept Consulting Inc, which he started in 1999. Since then, he has been particularly active in developing and extending open source content management systems to allow people to get closer to their content. Before starting OpenConcept, Mike had worked for a number of national NGOs including Oxfam Canada and Friends of the Earth.