Web Standards RFP

You know, I think the language you've used is alright. I would imagine that if the vendor wants the job and has the RFP they'll be able to make sense of it. It would be in their best interest.

You might want to say, "At a minimum, Valid XHTML 1.0 and CSS" and then let them work the rest out. Not that it should matter, unless you want these sites to be tableless -- if you don't want that you might want to say something like:

"Tables should not be used for presentation." Or "CSS should be used for presentation."

Keith, I was also thinking of "vendor will follow best-practices for separating content and presentation," though that seems vague. "Use CSS for presentation" is better.

So YOU wrote that RFP... we cheered when we saw it. While I completely believe that if a vendor doesn't understand what you mean by valid XHTML/CSS and WCAG that they're not going to be able to deliver on what you actually want.

Of course there's the millions of articles on business advantages to standards/accessibility. From search engine optimization to lower file size.

From a client perspective, I've found that the real seller comes down to the fact that their website will be less expensive to maintain and will be accessible to more users - whether that user has an impairment or whether they're browsing on a non-standard browser device (blackberry, etc). The flexibility and control that you have after the fact with a proper standards-based build is the real cost saving and advantage.

In the public sector, I also point to the US and UK legislation around accessibility and suggest that since Canada generally follows the UK's lead in telecommunications and technology standards and legislation that it's pretty inevitable that within the next 2 years we're going to see something akin to Section 508 here in Canada and that by developing according to the standards and WCAGuidelines an organization is going to not just be ahead of the curve, but save themselves a costly redesign or rebuild in the near future.

*nix users are going to be using either on Moz or KHTML (Safari) rendering engines, so specifying Moz and Safari should take care of those users. We've found zero deviation in rendering between platform variations of the Moz engine, and that's pretty much all you're going to see in the majority of *nix users.

We recommend XHTML Transitional rather than Strict. There are still enough implementation and browser issues with Strict XHTML rendering that we don't believe that the benefits of Strict will outweight the liabilities for years to come. And migrating a site from Trans to Strict is not going to be a major issue, by the time that Strict becomes viable there will be simple migration tools available (assumption, but pretty safe assumption give the current status of HTMLTidy and similar tools that already achieve this).

The issue with specifying CSS2 is that although it enables standards-based layout and build techniques, it does not implicitly prescribe them. It's implied, but not prescribed. I think that adding a simple i.e. in to your RFP (i.e. "Valid CSS2 and XHTML - i.e. tables should be used to contain tabular data and not to facilitate visual layout") is sufficient to delimit the level to which these standards must be implemented. I find that's the easiest line in the sand to draw between companies that "get it" and those that don't.

I think that those browser guidelines are excellent, although I'd move Mozilla on Mac up a notch, since if it works on Win it should work on Mac.

Thanks Paul, that's great advice. Just so I'm clear on this--you think Mac versions of Mozilla/Firefox/Camino should be listed in the Full Functionality row? (I guess that makes sense, now that I think about it.)