Very nice and interesting post about W3C Validation Services and standards for the big boys. I was amazed that such reputable websites did not validate their code yet. I guess because they have very large websites ?

W3C Validation Services will increase your website loading speed, search engines crawling speed, and website indexing rate.

Very Nice Post, thanks for sharing

OpenText Website is unfortunately not built on RedDot OR Vignette (coincidence or do we have to wait for those two to sort out where they stand?)

*I admit: Which is why I decided to work for them now.

The cost/benefit of adopting best practices in design, compliance, and markup is something vendors have to be cautious about. At Percussion, we started with a “everything is pure XML/xHTML” approach back in 1999 and have more or less constantly been forced by market demand to be more lenient.

The reality is the Web is a constantly changing place. The real test of a CMS is not whether it generates good markup, but whether it can generate ANY markup with equal amount of effort. When we redid our corporate Website, we actually put in a few examples of non-compliant stuff just to showcase that it was easy to do too.

I’m going to run all the tests again in a week or two. Interesting to see who else improves.

You also do better than IBM on the deeper pages. They don’t all validate, but have very few errors. The target attribute, for example, isn’t valid with your DOCTYPE.

So, I’d say you’re in the lead at the moment.

(If your intersested in folloing my work ive restarted my blog and are posing some about it. http://swippen.wordpress.com )

The “Nobody said this was a #1 requirement for the site” was meant to be covered by the “Nobody knew it mattered” or “Someone decided it wasn’t important”. The distinction was meant to be ignorance versus a crime of omission.

I agree 100% with everyone else you said. It is very time consuming to analyse all the errors to determine if that are generated by the product, some third party integrated code, or something implementation specific oversight. We often suffer from malformed markup from analytics vendors and others, but we try to send it back! When I set up this blog, the FeedBurner markup for the simple RSS link wasn’t valid.

I think maybe the most important point is that some of them clearly never even checked if it does validate, which shows the wrong kind of attitude. Accessibility really is a massive part of the RFPs that I see, so they should really care about it. I think I’ll run the test again in a few days and see if any have improved.

And here’s hoping no-one does the same tests on the sites I’ve been involved in. I wouldn’t expect any of them to have 100s of errors as most did validate at some point. But I’m concerned not as many would get the all clear as I’d hope.

I do blame the Rich Text Editors for a lot of the errors, but I think they’re improving with the new generations of CMS produts. Quite a few of the vendors we use have just switched or are about to switch their embedded editor. FCK and Tiny are on the list.

As an example, here is a complex design which is properly progressively enhanced. The home page still validates, but errors have crept into the depeer pages. The rich text editor in this case does not enforce ALT tags on images, and inserts paragaph tags into bad places. The next release of this product changes the editor.

Does this mean that it is important for Corporate customers to have valid markup, but not for Enterprise customers ?

http://validator.w3.org/check?uri=www.immediacy.net&charset=%28detect+automatically%29&doctype=Inline&group=0

With Immeiacy as long as the templates validate then you can be 99.9% sure your site will also validate.

This IS going to hurt.

Note: As Escenic’s presentation layer is implemented in JSP according to customer requirments, it’s up to each customer (and/or implementation partner) to make sure the JSPs generate correct code, whether it XHTML, RSS, PDF, or other formats.

That low-down ampersand just recently got in un-encoded – it’s fixed now. Btw.. the doctype on day.com is HTML 4.01 Strict.

Getting the code to pass the validator really isn’t rocket science. Most of these vendors do many, many things that are much more complicated in their products, and even manage to do some of those things flawlessly.

I wouldn’t beat up the vendors about their sites not passing the validator. (And I’m in no position to, either, since the CMS Watch site fails miserably. In our defense, we analyze technology, we don’t build it).

At any rate, it’s more important to know what the errors are and if they’re caused by the CMS. Common problems from your small sample are the analytics JS trackers (“just copy & paste this code to your page” and they give you non-compliant HTML) and URLs incorrectly encoded, and a lot of pretty basic templating mistakes. We can rule those out.

That leaves two important things to look for:

* Code generated by the CMS that won’t validate.

With a “straightforward” CMS, this can get you into trouble as soon as it generates a menu (and incorrectly nests elements, etcetera), since those will be generated by the system in a way that’s almost impossible to change. With the more “developer platform”-like systems, this is mostly the responsibility of the template coders, but you may still run into problems with smaller chunks — i.e., the internal links — which have to be generated by the CMS.

* Code generated by the editor that won’t validate.

It can be very easy to generate malformed HTML with the editor embedded in the CMS (whether the vendor built it themselves, or, more commonly, used FCK or Tiny etc.). This is often due to configuration of the editor and the pipelines used to pull content up (for editing), then clean up and save again. If you want real accessibility, the editor will also have to enforce rules on users (i.e., add the alt and title tags!).

This one sounds like its easier to check — especially if a well-known editor like FCK or Tiny is slotted in, which you’d expect you could find out about quite easily what they’re like. In practice, however, because after you save, the editor will clean up the rich text, then maybe another component (i.e., Tidy), then it might get escaped for storing in a DB, there’s character encodings to consider (which can be different in interface, front-end, DB, etcetera)… it can be a mess.

These two are pretty hard to verify from looking at the vendor’s site alone. You really have to do extensive testing to see if you could get your design into the CMS without breaking validation, and then see if you can actually keep creating valid code from content, as well.

Still, they should have it high on their list of priorities to set an example themselves. It gives the impression that they don’t really take their customers seriously, as if they’re saying “Hah. Who’s ever going to check the code?”.