One of the things I’ve been doing at work recently is to work on a web checklist, the idea of which is to provide some quick and easy tests for someone other than the developer to carry out. Reading through it, it occurred to me that something along pretty much the same lines might be useful to people in general, so I’ve revisited the idea here. It’s important to remember that you should obviously take more than this into consideration when building a site, but testing for these things will give you a flavour of whether or not a site is likely to be accessible (amongst other things).

The items break down into three broad areas: coding, content and function although these obviously overlap somewhat. Each article will focus on a different one of these broad areas.

This one will focus on coding.

Use a DOCTYPE

The DOCTYPE is used to indicate the standard against which your pages will be expected to validate, and serves to indicate to the user’s browser that your page should be rendered in “standards mode” — otherwise it will be rendered unpredictably in “quirks mode”. Your chosen DOCTYPE must also unclude the appropriate URI for that otherwise it will not be correctly recognised.

You should try to avoid the use of transitional DOCTYPEs as the only advantage of these is that they allow you to include presentational and behavioural elements in your HTML code which should instead be held in the css for presentation or JavaScript for behavioural elements.

Validate your HTML

You should ensure that the HTML validates. This will ensure that your sites are easier to maintain, and that they will behave in a more predictable manner across a range of browsers.

• If the site is publicly available on the internet and does not require dynamic input, go to http://validator.w3.org/ and input the URL to be checked
• If the site requires dynamic input or is not publicly available, view the source in a compatible browser, and copy the source into the “validate by direct input” part of http://validator.w3.org/
• If the site works in Mozilla Firefox and you have the HTML Validator Extension for Firefox, simply check the site in Mozilla firefox:
  • If you see in the bottom right corner of the screen, this indicates that the site validates against the stated DOCTYPE
  • If you see in the bottom right corner of the screen, this indicates that the site does not validate against the stated DOCTYPE
  • If you see in the bottom right corner of the screen, this indicates that the site has validated with warnings. You should review the warnings to see what they are, but unless there is a specific reason not to do so, a page that has validated with only warnings has no outright errors and should be considered valid.
• In general, remember that the W3C validator is the validation engine of the web standards body, so if this is known to produce a different result to an alternative validator, the way in which the W3C validator works should be given precedence

Using Stylesheets

Colour and layout should be carried out on your site by the use of css. The css should not be embedded within the content of your page (e.g. by using style="font-weight:bold".

Using css will allow a user to instruct their browser to over-ride your stylesheet with their own preferenced if they find your colours, text size or layout difficult to use.

You should also not use the <br /> element simply to create additional spacing — paragraphs should be created using the <p> element and the <br /> element only used where a line break is specifically required in the document flow — for example in poetry where a new line is required but the new line is still part of the same verse (equated here to a paragraph).

Avoid Layout Tables

You should therefore ensure that you have no tables in your web page, other than tables used to present tabular data.

If you are using Microsoft .NET as your development platform (and a very useful and powerful platform it is too), then you should be aware that a number of .NET features add tables automatically so you must be very careful about the way you use these, although if you do wish to use them it is possible to download CSS Friendly Control Adapters and incorporate these into your site to prevent it from including unnecessary tables.

Note however that there are many .NET controls which actually do involve the presentation of tabular data — such as the GridView control — and it is perfectly appropriate for these to use tables in this manner.

To test whether or not a site uses tables, use one of the following methods:

• Examine the source code manually for table markup
• Use the Web Accessibility Toolbar for Internet Explorer or Opera, and select “Table Borders” from the Structure button. This will highlight all of the table borders on the page and you can manually assess whether or not they are data tables
• Using the Web Developer Toolbar for Mozilla Firefox, select “Table Cells” from the Outline menu. This will highlight all of the table cells on the page and you can manually assess whether or not they are data tables

Headers for Data Tables

If you do have data tables, ensure that any item can be specifically associated with any heading elements by using the <th> element with the scope="row" or scope="column" attribute to mark up the relationship hierarchy.

For example (totally ficticious data):

In this case, place, rainfall and mean temperature are column headings and should be marked up with <th> and London, Paris and Stockholm are row headings and also need to be marked up with <th>.

In short, you’re asking “what additional information is necessary in order to make sense of a figure of 110 taken out of context?” Obviously in this case, what the figure represents and where it is representing it are necessary, and therefore these have been marked up accordingly.

Metadata

Metadata is one of those things that doesn’t necessarily directly affect what content is displayed to the user, but certainly will impact on how likely a user is to locate your site through a search engine. Yes, it’s our old friend SEO. Although in this case it’s not really about optimisation, it’s just about making sure the search engines can see what your site is about, and then letting them do their job as regards search parameters.

What should you include? Well, how about who wrote it, when they wrote it, what it’s about, and what character set it is written in, for a start?

<meta name="author" content="Jack Pickard" />
<meta name="date" content="2006-11-06" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="description" content="ThePickards: Accessibility Quick Checks" />

Avoid Deprecated Stuff

The FONT element and hspace, vspace and target attributes have been deprecated and should no longer be used. The equivalent presentational effects to these can be carried out by using the presentational layer of CSS appropriately, and if you must open links in a new window (the thing that the target attribute was mostly used for), then this can be done with appropriate use of the behavioural layer of javascript — there is a guide to opening new windows with Javascript on 456BereaStreet.com.

Note that either of the Strict DOCTYPEs will not validate if deprecated elements or attributes are used, so you do not need to carry this check out as a separate check if the page has already been shown to validate against a Strict DOCTYPE.

Language Declaration

The language should be specified on the html element so that search engines can more easily index the content and cater for someone searching for a specific language. You should also indicate the letter direction (i.e. English writing goes from left to right).

Note that if you are using an html DOCTYPE, you should declare the lang and dir attributes; if you are using an xhtml DOCTYPE you should declare the xmlns, xml:lang, dir and lang attributes:

Use both the lang and xml:lang attributes when specifying the language of an element. The value of the xml:lang attribute takes precedence.XHTML 1.0 Specification

Note that lang="en" is commonly used to refer to English generically: unless you need to specify “as used in the UK” or “as used in the US“, then you can probably get away without needing to specify en-GB or en-US respectively, although if you’re pedantic about spelling words like what I am (don’t you dare take the u out of my colour), then you might well want to be that bit more specific.