CMS & Validity

What CMS tools are still generating invalid code? As a webmaster sitting on top of a recently purchased CMS (Stellent), I’m empowered to dive into the belly of the beast and make the code valid.

Isn’t that the whole point of a CMS? To give us modular handles to keep our code neat and tidy. I find it hard to believe that open source CMS wouldn’t work this way. Am I naive to think that Interwoven and Vignette also have this ability?

I see people talking about content management systems preventing us from setting validity as a level 1 priority in WCAG 2.0. And while this may be true…I’d like to question this. Specifically, I’d like to see examples of invalid code produced by current versions of Brand X CMS.

And as for legacy pages and legacy systems, I’d suggest setting goals based on when a page was published/redesigned. New sites and sites being significantly redesigned should meet validity standards now. Legacy pages published priory to X date could be given a grace period. Cool thing about this grace period, is it encourages you to archive your outdated garbage.


  1. > What CMS tools are still generating invalid code?

    Heheheh…mine! All three of the ones I’ve made produce valid (X)HTML/CSS and meet accessibility guidelines. Though the first one back a few years ago used tables for layout and the management interface itself wouldn’t pass an accessibility test, so I guess two and a half.

    The systems that I’ve found to produce the best output give you the most control over every character in the templates. It restricts its accessibility and compliance to the skills of the web designer you have, but if you have a good one you can make it produce excellent code without getting held back by the programmer’s knowledge of markup.

    The most difficult part for me in making a CMS produce accessible markup has come from allowing users to paste from Word documents while keep the formatting (thankfully, we now have the Tidy PECL extension for PHP). Some people say that they can’t predict where the end tags will come in when working with dynamic blocks, but if you modularize your system enough and stick to object-oriented programming that doesn’t even start to present an issue.

    BTW: I never responded to your question of where I ended up as I’ve waited for the last few months to hear back about a Senior PHP Developer position for a rather large ‘net company back in Northern California. They still haven’t said no (I bug them periodically), but contracting like mad in the meantime. :-) Not holding my breath, but it sure would feel nice to head home…

  2. This has been my rant of late. They are not all CMSs, but to name a few of the vendor products we are tied to that still produce invalid, inaccessible code: PeopleSoft, SCT Banner, PostNuke, Blackbaud (Raiser’s Edge), Blackboard.

    In some of these instances, we are prevented by the license from changing the code, and in others (ie PostNuke), hacking the code breaks the update process, and there are important security updates that have to be done.

    For an example: . This is managed by PostNuke (it was not my project). There are 29 validation errors on the fornt page.

    However, I don’t think this is an excuse to not require validation as part of the level 1 WCAG priorities. I think this is an excuse to put some major pressure on these vendors so they stop giving us crap. PostNuke is open source, so _someone_ should be able to fix it.

  3. I have used 2 products, ContentXML 3.1 (current version) and Ingeniux CMS 2.0 (which is an older version than what is available today).

    ContentXML will force all user-input HTML to valid XHTML. If you try to input invalid HTML it will give you an error message.

    Ingeniux CMS, at least the version I used, couldn’t put out valid XHTML if you wanted. It forced all code to invalid HTML; for example, if you closed an IMG tag, the product would remove the closing tag. (I dunno about the current version of the product)

    Also, I use Blogger for my personal blog. Blogger will force your HTML to valid XHTML automatically. Doesn’t seem to be rocket science.

  4. Textpattern! Its the shizzy, and considered to be more of a CMS than a blogging tool.

    However, valid code is one thing, it does have a nasty habit of sticking in some inline css in some places…

  5. We have started implementing a product called WebEditPro, produced by a company called Interspire. You can set it to produce valid XHTML, which it does fairly well.

    It works with static HTML files rather that databases and templates, and uses Dreamweaver-esque “template tags” to allow editing of only certain portions of the the page.

  6. This is encouraging. I have a strong sense that validity is crucial to the next evolution of the web. As we move to semantic data, our pages remind me more and more of parameter data areas.

    We should always design the visual content of our sites with the human eye and brain in mind. But we need to elevate the content of our pages above the need for dreary manual sorting and sifting. A little more effort on the CMS/Developer side can free the data to be used by both man and machine.

    This will allow the next wave of development to further crystalize massive amounts of data so that our creative minds can see new connections that were buried in a sea of senseless data before.

Comments are closed.