Quite often I’m asked to review a client’s website for accessibility. One of the first things I always do despite the desired conformity level is to validate the (X)HTML (validation is a prerequisite of “aa” conformance).
Here are the most common error’s I come across when validating to XHTML.
- Elements and attributes in upper case. All element names, attributes name and values should be in lower case to meet XHTML specification.
- Missing attributes. XHTML requires certain attributes to be specified. Such as type on script tags.
- Depreciated elements/attributes specified. XHTML has a smaller subset of HTML attributes due to the separation of presentation syntax to style sheets. All height, margins and other style-related values should be moved to the style sheet.
- Closing tags: All tags should be close to ensure validation. Inline tags such as img and br should always be self-closed. Ie. <br /> and <img /> As this will case further validation issues down the document tree as the browser miss-interoperates future closing tags.
Rationale:
It’s important to ensure that your page meets it’s declared doctype as some errors prevent the page rendering correctly which then impacts the accessibility of the site and may in some cases prevent the site from rendering at all.
Other than the accessibility considerations, a page that doesn’t validate indicates to me that a developer/designer isn’t aware enough of the implications of the code they are writing, typically the page was created in a rush and I’m less likely to see any of the more advanced approaches to accessibility, I would consider essential for a good user experience.
Caveat – In some instance, a page can be invalid but still accessible. It used to be that .net added attributes to its generated HTML willy nilly. As I say this is an indicator to do some more in-depth analysis.
Matthew Goddard 