• They do not apply to webpages which are purely recreational and have no information content.
• They do not necessarily apply to systems which are internal, or whose intended users are limited to an Organisation and specific external partners ("Intranet").

• All HTML documents are checked with an HTML validator.
• Documents are validated at HTML level 2.0, 3.2 (Wilbur), or future specifications when available.
• Using a DTD other than the standard one, include an appropriate DOCTYPE declaration. In the case of a DTD that is NOT standard or widely-known (eg those available from WebTechs validation service), the DTD itself is referenced in a comment within the document.
• HTML documents are validated successfully.
• Validation errors are noted by the author. Such notes are delivered separately to the HTML documents (provided they are referenced by a comment in the source), and describe the purpose of the invalid construct, together with its effect in several browsers including text-mode browsers (the comment "no effect" is acceptable). In the case of an invalid but established construct, a reference to an existing analysis is sufficient.

• All HTML documents include an appropriate TITLE.
• Documents may include other header elements, such as relational links, Stylesheets, Client-side scripts and META elements.
• Documents which are a "front page" or other principal entry point for a system include the following:
  • KEYWORDS and DESCRIPTION meta elements for the benefit of Web indexers.
  • A "REV=MADE" link indicating the document's author or maintainer.
    
  Other documents may include such headers.

• We may use any legal markup to determine document colours, but generally use RGB specifications to do so.
• We try to ensure a strong contrast between text and background. This implies light-on-dark or dark-on-light: colour contrasts are insufficient to cater for monochrome displays or colour-blind readers.
• Background images (where used) are small, and are of a similar colour to the BGCOLOR specified.
• Conspicuous background images are avoided in pages containing textual information.

• Images are used to complement text, but are NOT used to replace it. Examples of appropriate use are diagrams, graphs and geographic maps (which naturally complement text); inappropriate examples are passages of decorated text and imagemaps used to replace it.
• All images have ALT texts. Where appropriate, ALT=" " is acceptable.
• ALT texts for images which are also links, provides brief description of the purpose of the link. "Home", "Next", "Previous", "Search" are examples of good ALT texts; "Click Here", "Home Icon", "Binocular Icon", "Back to XYZ Homepage" are irredeemably bad.
• ALT texts does not duplicate nearby document text.
• ALT texts for larger images (eg those above about 10Kb) warn their size - for example "Global Composite Image (29K)" (although it may be appropriate to omit this in cases where any non-blank ALT text would be obtrusive).
• ALT texts for imagemaps, direct readers to a separate text toolbar; otherwise they are kept blank (ALT=" ").
• Where imagemaps are used, alternative means of navigation are made available to readers.
• Images uses height and width attributes, except as noted under Browser Compatibility below.

• <BLINK> is not used.
• <FONT> is not used in place of HTML headers <H1> - <H6>
• Emphasis tags such as <FONT>, <B> or <STRONG> are not applied to extended passages. They are appropriate to words and phrases, and (exceptionally) as much as a complete paragraph of text.
  
• <H1>...</H1> are be used exactly once in an HTML page.

General standards: particular cases are dealt with separately below.

• Subject to the validation standards above, we use nonstandard or proprietary tags in an HTML document.
• Whereas HTML pages are "enhanced", they are not dependent on proprietary markup. Specifically, all key functionality and information are available to an HTML-compliant browser not supporting the "extension".
• Undefined Entities are not used.

HTML constructs which render a document difficult to read due to known defects in popular browsers are avoided, regardless of the construct's validity in strict HTML.

• Use of < or > within a tag, in a construct such as <IMG SRC="forward.gif" ALT=">"> risks breaking parsers and are avoided.
• Comments are open with <!-- and close with -->. Use of "--" or ">" within these delimiters are avoided.
• Height and Width attributes in images are restricted to cases where neither the image itself nor the ALT texts are essential to the document. In particular, images which are navigation icons do not use height and width attributes, unless separate text-based navigation is also provided on the same page.
  
• When specifying document colours in a BODY tag, numeric RGB notation is always used.
• When using a floating image or table, "br clear" if possible is used ahead of any further images or tables.
• When using HTML Tables, provision is made to ensure the document is legible to browsers not supporting this feature.
• HTML containers (such as paragraphs or table cells) are explicitly closed.

A common and frequently serious author error is to seek to affect page presentation in a manner detrimental to a document's legibility for other users.

• Pages do not depend on a particular browser window, font size or colour table to be readable. Indeed, they do not depend on any visual presentation whatsoever, except where the information content is inherently visual in nature.
• We do not use constructs which make assumptions (explicit or otherwise) about a reader's settings. Examples to be avoided are full-screen tables or divider GIFs whose size is expressed in pixels.
  <TABLE WIDTH="95%">is acceptable; <TABLE WIDTH=500> is not.

• Documents available in more than one language are presented as parallel hierarchies in the languages concerned.
• HTTP content-negotiation are used to determine the default language presented to the reader.
• Every document in a multilingual hierarchy include links to the other languages available.

• We use style sheets to enhance webpages, and do so when seeking to determine document appearance.
• Style sheets are not visible to browsers which do not support them. This shall be tested.
• Style sheets are not used in a manner detrimental to accessibility for browsers not supporting this feature.

• Frames are used, subject to the validation requirements. Note that since they will not validate as standard HTML, a report will always be required.
• Information provided via a frameset is also made accessible unframed via the NOFRAMES section.
• The NOFRAMES section provides readers with a complete alternative. The use of a link to a separate version is restricted to those occasions where it is large in (byte) size.
• Use of more than one frameset-based layout on a site is avoided.
• All external links in a frameset page uses the target attribute to avoid embedding another website in a frame.

• Client-side scripting languages such as Javascript is used, provided it does not detract from the page's accessibility to browsers not supporting or enabling this feature.
• Script pages is inspected in browsers not supporting the scripting language (NOT merely browsers with this facility turned off) to ensure satisfactory appearance.
• Script pages are subject to HTML validation requirements.

In the case of dynamic pages generated by CGI, SSI or other server interface, it is not realistic to validate every possible page generated. However, output will generally take a prescribed form or one of a limited number of prescribed forms.

• Dynamic pages are represented by sample outputs of the program. These sample pages are subject to the standards described for static documents. Every major path through the program is represented by such a sample output page, and tested with the same attention as the software itself.
• Dynamic pages which include a user's input may be beyond our control. Nevertheless, we seek to anticipate any potentially-disruptive input; for example, any HTML markup could be stripped.
• In all cases, we ensure that user input cannot be used to compromise system security, or the accessibility of other information on the system.