Cimex Media’s
Guidelines for xHTML/CSS/JS projects

1. Abstract

The purpose of this document is to collate guidelines for all xHTML/CSS/JS work at Cimex Media. It is not an exhaustive list and may change over time, but as it stands, serves as a tool to facilitate the quality assurance process of any website. Unless otherwise agreed, all websites developed by Cimex work towards these guidelines.

2. Devices

Ensure pages comply with Cimex' browser compatibility statement.
Ensure content is still accessible in a range of browser sizes, including the very small sizes required by handheld devices such as PDAs or mobile phones.
Ensure content is still accessible with CSS switched off.
Ensure content is still accessible with images switched off.

3. General requirements

Pages should validate against chosen DOCTYPE. If your pages have multiple states (such as templates populated by dynamic content or forms), ensure validation persists across all of them.
Identify the language in the <head> of a document. For example, when using any variant of XHTML 1.0, the <html> tag should read:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">.
All pages should have linked print stylesheets which optimise the page for printing.
The <h1> element should precede core content.
Allow for font-resizing. Browsers that do not support re-sizing of absolute font-sizes should be fed relative font-sizes. Furthermore, it is important that design should remain cohesive when fonts are scaled up/down two sizes from default.
Use skip links to aid navigation. For example, if navigation precedes content, add a 'skip to main content'.
Ensure the core content of you site is still available with CSS, Images, Javascript, Flash or other proprietary plug-ins disabled. This ranges from avoiding the use of pseudo links such as "javascript:dosomething" in the href attribute of your <a> tags, pop up windows that depend on JS being enabled through to JS dependent form validation etc.
Implement error page(s) and ensure they are functioning correctly on both staging and live servers. At the very least, there needs to be a 404 error page which provides meaningful and helpful feedback.
Use keyboard shortcuts, such as access keys, to compliment navigation. However, due to the lack of any convention and the inconsistencies in the manner in which they are used between applications, the benefits of access keys are debatable. I would recommend 's' for skip links and '1' for home page but other than, only use if specifically requested by the client and accompanied by a key on the accessibility statement ('0' on the home page).
Not essential, but an accessiblity statement is good practice. Statements clearly identify an attempt to comply with the DDA, allowing developers to advise users about the site's accessibility features (e.g. a key, listing what access keys are in use). They also represent an opportunity to educate users on options that can benefit their browsing experience (e.g. increasing their default text size) that may otherwise be unknown.
Don't open new windows (without a very good reason). Browsers have this capability built in - forcing this behaviour using target="_blank" or similar, disables this functionality and also renders the back button useless. Back buttons are understood by all users, irrespective of how they are browsing the internet - don't break this very useful (and rare) convention!
Where possible use semantic filenames e.g. browser-statement.html. Words should be spaced with hypens rather than underscores to comply with UK Government guidelines.
Don't assume that you will be the only person working on the site. Comment your code with the intention that your colleagues can understand the core structure of the document quickly and efficiently. This includes indicating the id/class of a closing <div> tag:
1. <div id="content">
2. <p>Consenibh niscilit nonsenibh, platea volut diamet diamcon, msandre eum iureet illa.</p> <p>Consequam uissit eget aute velit eugiate vullandioisi eui; adionsequat porta quation dui. Conulputem euguero qui commod consent ut quatie sagittis dolendrer.</p>
3. </div>
Don't rely on colour alone to differentiate links. This is especially true for links within body copy, which under most circumstances should be underlined.
Repair/remove broken or redundant links, especially <a href="#">my link</a>. W3C's link checker can help out.
Check the page download time is not excessive. There are various tools that can assist you.
Although it is not essential (avoids unwanted 404s in web stats), it is certainly good practice to include a favicon (This tool can help).

4. Semantics

Ensure pages use both unique and meaningful page titles (<title>).
Use proper heading elements. This is doubly important as the reasons for using them go beyond semantics: There are also significant benefits to search engine optimisation and the communication of document structure. As a footnote however, remember not to skip levels (e.g. h2 elements should follow h1 elements, h3 elements should follow h2 elements).
Provide text equivalents for all images/image maps. This includes the images used as submit buttons within forms.
Lists should marked up accordingly using either <ul>, <ol> or <dl>.
Use real <hr> tags and style accordingly (as opposed to images or other visual alternatives).
Don't forget metadata just because it's invisible. The web is a mass of information - metadata improves semantics, searchability and increases the long term viability of the content. As a footnote to this, don't paste the same metadata on every page. I'm working on a default schema we can use on every page which will be based on the e-GMS v3.0.
Ensure links make sense when read out of context. Screen readers have an option to list all the links in the page in a seperate dialogue, making 'More' or 'Click here' links frustratingly useless.
Provide as much semantic goodness as possible. Elements such as <abbr>, <acronym>, <address>, <cite>, and <code> enhance the semantics of content when used appropriately.
Clearly identify changes in the natural language of a document's text.
Avoid concatenating words which may confuse screen readers e.g. homepage should be home page, sitemap should be site map.

5. Forms

Use properly labeled form elements <label>, <fieldset> (& <legend>), <optgroup> etc. Please note, checkbox and radio button elements should appear before their labels.
Where possible use server-side validation over Javascript. When providing feedback using this approach, try and get the focus of the page directed at the error message. This prevents screen readers repeating the content prior to the error when it is reloaded.

6. Data tables

Make use of the summary attribute on the table element.
Use captions for a data table's title. This should come immediately after the table element and before anything else.
Use the <thead> element for table head, <tfoot> element for table footer and <tbody> element for table body.
Identify row and column headers using <th>.
When building complex data tables, make use of the more effective 'id and header' combination over and above the 'scope with col (and colgroup) and/or row (rowgroup)' combination.
Don't use empty cells to provide aestheic effects.
Data tables are a notorious accessiblity issue so make sure you test with adaptive software.

7. Colour

Ensure that all information conveyed with colour is also available without colour.
Ensure sufficient contrast between text and background colours.
Ensure the legibility of the text is not compromised by the background (or background image).

8. Other useful tools

The Web Developer Extension for Firefox is an essential. Chris Pederick deserves a nobel prize (or something) - go and give him something nice.

Maxdesign have a very comprehensive web standards checklist (PDF).

A good range of testing tools is available on the UITest website.

Cimex Media’sGuidelines for xHTML/CSS/JS projects