There's plenty of good material in the latter half of the UK government accessibility guidelines, beginning with section 2.4.4, and it won't be repeated here, except for elements that might benefit from interpretation.
This is a particularly useful section. It defines standard accesskeys covering the numerals 0 to 9 and the letter S. The best way to implement accesskeys is to see how they're used in the HTML code of a decent government site, such as Number 10. The Office of the E-envoy site sometimes has accesskeys (early 2003) and sometimes doesn't (early 2004). It's hard to know what to say about that, except that there is some debate about whether accesskeys are genuinely useful.
Another very useful part of the government guidelines. It's a large section, yet concise, so requires no interpretation here. If you require more details on colourblindness, and particularly which versions are the most common, there's additional information here on the Tinhat site - Usability and Colour.
Another good section. There are two elements worth expanding upon.
"The options offered in a drop-down should be repeated as text links on the same page."
In the commercial world, the usual method of working is that the main navigation options, those that appear when the drop-down fails, should point to menus that offer the options that would have been visible if the drop-downs had appeared. That way there's full accessibility, but if the drop-down fails then navigation requires one extra page and click. Under a strict interpretation, it looks like that's unacceptable under the government guidelines.
"They (pop-ups) are disorienting for users who cannot see that a new window has been created."
In usability circles, the usual recommendation is to include text (or Alt text or Title text) that tells users that a new window will open if they click on a particular link.
Some worthwhile content here, but a lot of it repeats WAI guidelines. There's also one inconsistency - it tells you how to deal with spacer gifs, although earlier in the guidelines they were banned.
Here's a strong statement from this section. Something to think about: "Do not use an image when a text link will work just as well."
This section gives details of how to make video and audio more accessible, but perhaps the first question should be - do you really need multimedia? It's best to avoid it altogether if you can, or limit it to entertainment items that don't require accessibility fixes because they only include non-essential material.
Most of the guidelines here repeat WAI recommendations.
"Avoid using tables to arrange text documents in columns." Er,
except that's how the guidelines page itself was originally coded, with tabular
columns for text. One particular use of vertical columns you should try to
avoid is where the horizontal alignment is meaningful. In general, CSS2 formatting
is preferable to tabular formatting.
"Provide summary information for a table using the 'summary' attribute." Browsers can't read this attribute yet, but they may be able to do so in the future. Under WAI guidelines, summaries are for data tables, not layout tables.
"Table width should be set using the "%" value rather than a fixed pixel value." The original guideline page didn't conform, but hey ho! A practical tip - watch out for nested tables with a 100% width, they often foul up in Netscape 4.
"Links do not have to be in the de facto blue." Meaning default blue, presumably, but let's not get trivial. Fact is, default blue links are the easiest to recognise, so are preferable, but others might be OK. Here on Tinhat the links aren't quite default blue, because it doesn't go with the colour scheme, but the blue used is close enough for them to be instantly recognisable. Links grouped together in navigation areas can more easily take on alternative colours, because their grouping clearly indicates that they are links.
Seen all this before? Yes, if you read the earlier parts of the guidelines.
These all relate to W3C recommended attributes that hardly any browsers can understand right now, including most screen readers (talking browsers), but they should be useful at some point in the future, so are worth including. Another is the Abbreviation attribute.
The remainder of the document mainly details accessibility tools, looks at PDFs and recommends further reading. On the subject of PDFs, the best advice is to avoid them if you possibly can. Their main advantage is that they print well - but then so should your HTML pages, so the advantage is a weak one.
Note: the government guidelines are rarely used in practice. See UK Accessibility for more details.
This Tinhat page is valid XHTML to WAI level-A standard
UK accessibility intro + menu
UK accessibility site reviews
Comment on DRC Report
Simple WAI level A checklist
Level A -
TinHat Level A+
Tips for web editors
Non-HTML files (PDFs) and accessibility
Gov guidelines for UK gov sites (intro)