1. Skip Navigation  
  2. What's New  
  3. Search  
  4. Contact Me  
  5. This Site

As a web developer for a Local Authority, with quite a keen personal interest in accessibility, I was interested to read the document eAccessibility of Public Sector services in the European Union that was produced for the European Union during the United Kingdom's presidency and is available on the Cabinet Office website. This official document takes a firm line on what is required to achieve various levels of accessibility and it occurred to me that a lot of sites (and not just public sector sites) that claim AA conformance would fail against these criteria.

It's generally considered to be fairly easy to achieve level A conformance (compliance with all Priority 1 checkpoints), and virtually impossible to achieve Triple-A Conformance (compliance with all Priority 1,2 and 3 checkpoints). Double-A conformance (compliance with all priority 1 and 2 checkpoints) lies somewhere in between. It can be achieved, and it is practical to achieve, but it will not be achieved without a certain amount of thought and effort.

It's important to indicate that everything that follows is my own view and is not necessarily that of my employer. I have selected a number of Priority 2 checkpoints which I believe are frequently ignored or not properly satisfied. To achieve Double-A conformance, which is mandated for public sector websites, all of these checkpoints must be satisfied. This may not be easy to achieve for large sites with many thousands of pages, but this is what is required to achieve level AA.

Checkpoint 3.1 - Use markup rather than images

This checkpoint states: "Where an appropriate markup language exists, use markup rather than images to convey information." The guidelines underlying this checkpoint specifically state that you should "avoid using images to represent text". This means that if you have any images on your page which are basically used to convey textual information, but you have used an image because it has a pretty background (which does not add to the meaning of the text) then you are failing to meet this checkpoint.

Checkpoint 3.2 - "Create documents that validate to published formal grammars"

This is fairly simple. Pick your document definition, include your DOCTYPE in your page, and make sure ALL of your pages validate to it. Test your pages using an automated validator before they are put live (you can always use the W3C's Markup Validation Service. If you have errors you must fix them, or you are failing to meet this checkpoint. The difference between Strict and Transitional or Loose DOCTYPES is that Transitional or loose DOCTYPEs allow the use of presentational elements and attributes in your markup (contravening checkpoint 3.3), so if you want to ensure you achieving level AA accessibility, there is no reason why you should not at least use HTML 4.01 Strict. Using a Transitional or Loose DOCTYPE will make it easier to validate, but if it would fail to validate against HTML 4.01 Strict then it would be failing to meet Double-A conformance anyway.

Sample DOCTYPE declaration:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

The eAccessibility of public sector services document indicated that this is the primary reason that the assessed sites failed Double-A conformance - "the finding that 99% of the sites evaluated still have significant problems in this area, is completely consistent with findings from other similar studies". This is surely compelling evidence that all web pages should be tested using a reliable automated document validator before they are made live.

Checkpoint 3.3 - "Use stylesheets to control layout and presentation"

The simplest interpretation of this is that your presentation should be carried out using stylesheets; the HTML should contain only the document structure and contents. For example, you should not set background colours or use the <font> element within the HTML.

More than that however, the use of tables to control layout is approaching failing this checkpoint - depending on exactly how you've done it. Using a data table is fine, because this is the table being used specifically for the structural purpose of presenting data.

If however you are using table, particularly with the use of the cellspacing, cellpadding or border attributes, then you are using markup to achieve a presentational effect. Which would certainly fail the checkpoint. If however, you are simply using the table rows or cells as containers, and your styling is carried out with stylesheets, then this is simply the equivalent of using the <div> container and you should probably be able to achieve this checkpoint.

Whether or not it is actually required to achieve this checkpoint, I would always recommend avoiding the use of tables other than data tables, because this avoids these potential problems in the first place.

Checkpoint 3.7 - Use quotation elements appropriately

This checkpoint states that you should "Mark up quotations. Don not use quotation markup for formatting effects such as indentation." This means that when you are quoting from a third party, as I am here, you should use either the <blockquote> element for block quotations, or the <q> element for inline quotations, such as used here.

CSS styling can be used to make your quotations more visible - you can indent them, change the default font family (as I have done) and choose the type of quotation marks you wish to use.

If you simply use " to markup quotations, without using the quotation elements, or you use the quotation elements for something other than quotations, you will be failing to meet this checkpoint. When content is devolved to multiple people (such as where a CMS is used), you will need to ensure that all users who could input web pages are aware of the proper procedure for entering quotations.

There are some problems however. You are advised not to use the quotation marks directly inside your markup, and instead take them from the stylesheet. The drawback with this is that the before and after quotes of the <q> element are not supported by Internet Explorer, and quotation marks don't show up. The pragmatic approach appears to be include the quotation marks in the markup directly, but to specify no quotation marks in the stylesheet to reduce the chances of anyone encountering double sets of quotation marks.

Checkpoint 13.1 - Use meaningful link text

This checkpoint states that you should "Clearly identify the target of each link", and that "link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links". Link text of 'click here' or 'more information' or 'read more' do not make sense when read out of context and would fail to meet this checkpoint.

Checkpoint 3.4 - use relative rather than absolute units.

I have deliberately left this checkpoint to the end because there are differing viewpoints on it, and because so many sites continue to use pixel units to produce a fixed width site. It's going to be controversial, but bear with me...

The checkpoint states "Use relative rather than absolute units in markup language attribute values and style sheet property values". The description goes on to expand even further "For example, in CSS, use 'em' or percentage lengths rather than 'pt' or 'cm', which are absolute units".

The main problem that this leaves us with is that one of the most common units, the pixel, is not directly mentioned. The pixel unit is, according to the original Cascading Style Sheets specification, a relative unit, because it is relative to the screen size and would be rescaled on a different medium - for example, on a printout. Yet it is apparent that this unit is not as scalable as other units such as 'em' and percent, which allow the user more control over the length units, and allow the display to be scaled proportionately to the users screen size. Indeed, in some places on the W3C website, the pixel unit is referred to as an absolute unit ("Note that use of px units or any other absolute unit identifiers...").

It is advantageous to allow the entire page to scale according to the user's screen resolutions, because this allows you to cater for users with unusual resolutions (such as any users still tied to 640x480, any users on WebTV and any users accessing the site via a PDA (Personal Digital Assistant)).

In fact, the author of checkpoint 3.4 intended that pixel be considered an absolute unit for the purposes of this checkpoint and has proposed that checkpoint 3.4 be clarified in the current specification.

I propose that we also make an erratum to clarify that the units considered "relative" in this checkpoint are those relative to the user's font settings - %, em, ex, but not px, pt, pc, in, mm, cm. As one of the originators of this checkpoint I certainly meant that, and apologise for having been a bit sloppy 5 or 6 years ago.

It seems apparent therefore that using pixel units in the stylesheets certainly goes against the spirit of this checkpoint, although it is certainly open to interpretation as to whether is would actually contravene the "letter of the law".

Does it really matter which way you interpret the checkpoint? Well, that depends on why you're addressing the checkpoint. If you're just doing it to claim Double-A conformance, then - with one proviso - probably not. If you're doing it because you want your site to be more accessible, then yes it does matter. A fluid site capable of adjusting it's width to the width of the viewing window is more accessible than any fixed width site. And what's that proviso? Well, it depends why you're seeking to claim Double-A conformance. If it's because you're a public sector organisation and you've got to have a site conforming to Double-A because this is what has been mandated by the UK Government, then I'm afraid you're in trouble.

The eAccessibility of public sector services document indicates quite clearly (page 51) that they believe a fluid design is necessary to meet this checkpoint.

Table height/width absolute values / CSS absolute values

The layout and overall visual formatting can either be 'rigid' where elements of the page are directed to appear in absolute sizes and positions on a screen, or 'fluid' where elements of the page have hints about relative sizes and positioning but can be flexibly scaled or rearranged to suit the particular display available.

This particularly facilitates people with intermediate levels of vision impairment - a very large, and growing, user group, but it also delivers benefits to many mainstream users.

With failure rates of 89% and 75% for the two items reported here, it is clear that such fluid coding of web pages is still not widely deployed.

The work behind this project was carried out by a partnership led by the RNIB, with AbilityNet (a UK charity providing expertise on assistive technology for users with disabilities), Dublin City University, and SOCITM Insight, supported by the RNID.

While the concept that you will fail this checkpoint and therefore be unable to achieve Double-A conformance is somewhat controversial, it is not simply my opinion. This is the official opinion presented by the European Public Administration Network, backed by the UK Government and leading disability charities. If you are seeking to achieve Double-A compliance to meet a requirement laid down by the UK Government, I would therefore suggest very strongly that you need to be looking at a fluid design.


There's a lot more that goes into achieving Double-A accessibility conformance than simply the checkpoints discussed here - there are the remainder of the priority 2 checkpoints and all the priority 1 checkpoints for a start! I have simply focussed on these specific checkpoints because I feel they are frequently ignored or misunderstood. I would like however to make it clear that unless you specifically looking to achieve a certain grade of conformance, and that's all you're interested in, then the most important thing is the user experience and the overall accessibility of your site, rather than simply meeting some checkpoints which in some cases may be out of date. However, if you're doing it because you need to achieve a conformance level, then you just have to grit your teeth and get on with it!

I would appreciate any comments relating to this article - please use my contact form.