This week we've been working on a project to optimise the W3C standards validation of one of our customer's websites and I thought it would be a good time to write a post with some tips and tricks on how a company might approach this same task.
What are W3C standards?
The World Wide Web Consortium (W3C) is an international organisation that develops (through extensive industry consultation and involvement) and manages web based standards that are aimed at improving website development and website design.
Within their saddle bag, W3C have a range of standards classified into:
- Web design and applications
- Web architecture
- Semantic web
- XML technology
- Web of services
- Browser and authoring tools
Typical organisations that are interested in ensuring their website conforms to W3C standards include government agencies, medium to enterprise businesses and organisations with strong standards and ethics policies. Of course this isn't to say other organisations don't implement these standards - just that these groups are the more likely to.
W3C Markup & CSS Standards
To help organisations conform to the standards, W3C have a number of free validators to check your website including:
- Markup Validator - checks for issues with the way the HTML (etc) has been coded
- Feed Validator - checks to ensure your RSS feed has the correct syntax so it can be understood by feed readers
- Mobile checker - checks for mobile 'friendliness' of a website
- Link checker - checks your website for broken links
- CSS validator - checks the CSS (styling code)
The two key ones we'll focus on in this post is the Markup and CSS (and we'll follow up this post with a discussion on accessibility standards).
When you start assessing the validity of Markup and CSS standards the key issue is assessing all the pages on your site and understanding which changes affect which pages (so you can subsequently test the fixes). The tools above let you check a single page at a time - not the best use of a developer's time! Enter the W3C Validator Suite...
Using the W3C Validator Suite
There are a few different tools we've tried in the past to analyse how well a website conforms to the W3C standards however W3C themselves have recently developed a cloud based service called W3C Validator Suite (which is in BETA) so I was keen to try it out and see if it simplified the analysis/change/test process somewhat.
The pricing starts at USD$50 for 250 pages through to USD$190 for up to 5000 pages. In our case we wanted to run a test across a website with about 2000 pages so we ponied up USD$110 to kick the process off.
After you purchase the appropriate service plan, you're taken to the Jobs page which has automatically commenced the analysis of the website you specified during purchase, as shown below:
When we ran this particular test (for a large 2000 page Joomla website) we started it at 8:45am and the service had finished checking almost all the pages by 9:45am. However it then took another 4 days before we could access the results! The reason was the W3C server crashed and started giving out '504 Gateway not found' errors - not great! But I guess it is in BETA so you have to expect an imperfect service at the moment. However when I contacted the support team they were fairly quick to get back to me (considering time zone differences) and they were nice enough to offer us free credits for use in the future to compensate (thanks!).
When we finally were able to login, the results were well laid out into three core areas: HTML/XHTML Validator, CSS Validator and I18n Checker. We were most interested in the HTML and CSS results.
At first it might look like there are a huge number of issues to fix, however one key thing you need to remember with content management systems (CMS) is that although the error might appear on every page, it is usually just one file/line that needs to be modified to fix it for all pages. This is obviously one of the 'pros' of using a CMS - if we had to edit 2000 pages it would be a nightmare!
What we also noticed with the tool is that although it certainly tries to group all the same errors together, it doesn't completely succeed - for example:
In the image below you can see the same error reported twice but just with different values - what might be an improvement on the tool is grouping pages into the overarching error (Property -moz-border-radius doesn't exist) and then by value (5px, 4px etc)

However the tool does provide the ability to group errors by resource (e.g. you can see all the errors in the file mydesign.css) or by message (as shown above). The view 'group by resource' shows you exactly which css element and line numbers need to be edited to fix the issue - nice!
Another feature which would be very handy is the ability to export reports to HTML (for saving locally) and PDF.
Overall though this tool is a great timesaver - time to send my devs the report so they can get stuck into assessing and resolving each one - good luck boys! ;)
Best Practice Tips
I've got three quick tips for anyone else running this type of analysis:
- Run the validation before you start securing pages to specific users and after you add all the content pages - otherwise the tools won't generally be able to capture all the pages and configurations.
- The more plugins and extensions you add to a content management system (CMS) the more potential for issues to fix - keep these to a minimum and try to choose those extensions which have been tested for W3C Markup and CSS validation already. This is pretty difficult with an open source CMS (as the quality of extensions varies extensively!) however what we usually do is build a 'template' site which contains the common extensions and resolve any W3C issues on it, then use it as the basis for future customer websites (so essentially each customer starts with a standards compliant website and we don't have to keep repeating the same fixes over and over again).
- Some errors or warnings will be specific to a browser vendor or CMS - don't just willy-nilly remove or adjust them without understanding what they might 'fix' for a website to be viewed in a specific browser.