Skip to content

Accessibility is getting better in CMS products

Written by James Robertson, published November 21, 2008

Categorised under: Content management, Usability & user-centered design

I’ve been facilitating CMS vendor demos for most of this week, as part of the final stages of a University CMS selection project. One of the things that has changed in the products is their support for accessibility, generally for the better.

The good news

There have been some encouraging improvements:

  • Some now include built-in “accessibility checkers”, which assess content against a wide range of accessibility issues. Far from perfect, they do at least highlight many common issues.
    • Cutting-and-pasting from Word removes most of the Word “junk code” that impact both web standards and accessibility.
  • Accessibility details can be added to images, links and tables. In most cases, this can be enforced.
  • A lot of the old-school formatting in the products has been replaced by the use of CSS.
  • By default, functionality such as calendars and forms produces reasonably clean HTML.

Still some work to go

Despite the improvements, there are still outstanding issues:

  • Having built-in accessibility checkers is nice, but not a lot of use if content produced by the CMS routinely fails its own tests. (This looked very odd during the demos!)
  • The checkers also don’t do anywhere near enough to correct (or help to correct) the issues, and can overwhelm the author with detail.
  • It’s often not clear exactly when accessibility is enforced. Is it during editing, when the page is checked in, later in the workflow, or before final publishing?
  • Vendor understanding of accessibility is still very weak, often no more than “well, we’ve published site x that met level 3, so we must be fine”.
  • Cutting-and-pasting from Word is still a source of problems, remarkable considering how important this is for authors.
  • Legacy HTML still remains in the products, such as setting the widths of objects in pixels, or picking colours out of Windows-style colour pickers (rather than using CSS).
  • Online forms produced by the CMS are particularly poor in terms of accessibility.
  • Having the CMS itself being accessible for authors is still a distant pipe dream.

What it means

Expect more from your CMS when it comes from accessibility. If the products you’re assessing don’t offer anything in this area, consider looking at some that do! (There are over 140 CMS products in Australia, so there’s plenty to choose from.)

Even if some functionality is offered, look under the hood to see what it really means in practice, and take nothing for granted.

Accessibility is an important issue, and it’s good to see that CMS vendors are finally making some substantive progress in this area. Still a long way to go, but hopefully we’re on our way.

Tags: ,

2 Comments:

  1. Adrian Sutton commented on November 24th, 2008

    It’s interesting to see the increase in demand for accessibility and standards compliance from products. While it’s been on the RFP checklist for quite a long time, it’s only recently that people are actually taking it seriously.

    What’s interesting to note is how little most CMS client teams actually know about accessibility, even when they know it’s a priority for their deployment.

    I work for Ephox and we’ve been talking with a lot of clients about accessibility and how to make it easier for the average author to create accessible content. It’s certainly not easy to get authors to understand the impact of even simple things like alt text. It’s one thing to require alt text, it’s quite another to ensure that you get something useful as that text.

    Even with our editor automatically cleaning up code pasted from MS Word, providing an accessibility report built right into the editor and really strong support for applying CSS stylings from a predefined stylesheet rather than inline, it’s still quite common for people to create inaccessible content. Mostly, the average author doesn’t care about accessbility, even if the team maintaining the CMS do and that’s not easy to fix.

    Fortunately, as more people demand better accessibility and actually look under the hood as you recommend, vendors will be under more pressure and will actually start scheduling development cycles to improve things. It’s certainly an area that Ephox has always paid a lot of attention to and will be paying even more to in the future – our next release is focussed almost entirely on making it easier to create accessible content.

  2. James Robertson commented on November 24th, 2008

    I agree. What we highlight to our clients is that it is their *internal* knowledge relating to accessibility that will be the limiting factor in achieving compliance.

    As you know, there is no one checkbox labelled “accessibility” to be ticked off.

    Instead, there are a lot of individual decisions to be made, particularly as the richness of site functionality grows.

    Authors also have to have the necessary skills, time and interest to deliver accessible content.

    At the end of the day, we need to improve both sides of the coin:

    * the capabilities of publishing tools

    * the internal people processes

    Cheers, James