- All HTML documents SHALL be checked with an HTML validator.
- Documents SHOULD be validated at HTML level 2.0, 3.2 (Wilbur), or future specifications from W3C when available.
- Authors using a DTD other than the above SHALL 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 SHALL be referenced in a comment within the document.
- HTML documents SHOULD validate successfully.
- Validation errors SHALL be noted by the author. Such notes MAY be delivered separately to the HTML documents (provided they are referenced by a comment in the source), and SHOULD 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 SHALL 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 SHOULD 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
Colours and Background Images
- Authors MAY use any legal markup to determine document colours, but SHOULD use RGB specifications to do so.
- Where colours are set by an author, they SHALL 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. Note that this implies that authors setting a text colour MUST also set the corresponding background, and vice versa.
- Background images (where used) SHOULD be small, and SHOULD be of a similar colour to the BGCOLOR specified.
- Conspicuous background images SHOULD be avoided in pages containing textual information.
- Images MAY be used to complement text, but SHOULD NOT be 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 SHALL have ALT texts. Where appropriate, ALT=” ” is acceptable.
- ALT texts for images which are also links SHALL be descriptive of the purpose of the link, and SHOULD be brief. “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 SHOULD NOT duplicate nearby document text.
- ALT texts for larger images (eg those above about 10Kb) SHOULD warn of 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 MAY direct readers to a separate text toolbar; otherwise they SHOULD be blank (ALT=” “).
- Where imagemaps are used, alternative means of navigation SHALL be made available to readers.
- mages SHOULD use height and width attributes, except as noted under Browser Compatibility below.
Appropriate Use and Deprecated Tags
- <BLINK> SHALL NOT be used.
- <FONT> SHALL NOT be used in place of HTML headers <H1> – <H6>
- Emphasis tags such as <FONT>, <B> or <STRONG> SHOULD NOT be applied to extended passages. They are appropriate to words and phrases, and (exceptionally) as much as a complete paragraph of text.
- <H1>…</H1> SHOULD be used exactly once in an HTML page.
General standards: particular cases are dealt with separately below.
- Subject to the validation standards above, authors MAY use nonstandard or proprietary tags in an HTML document.
- Whereas HTML pages MAY be thus “enhanced”, they SHOULD NOT be dependent on proprietary markup. Specifically, all key functionality and information SHOULD be available to an HTML-compliant browser not supporting the “extension”.
- Undefined Entities SHALL NOT be used.
HTML constructs which render a document difficult to read due to known defects in popular browsers SHOULD be avoided, regardless of the construct’s validity in strict HTML. All of the guidelines in this section are advisory.
It is not the purpose of this document to enumerate browser failings but authors’ attention is drawn here to a few cases. Authors purporting to write for the “majority” should be aware that most of these constructs risk becoming illegible in the popular Netscape browser.
- Use of < or > within a tag, in a construct such as <IMG SRC=”forward.gif” ALT=”=>”> risks breaking parsers and SHOULD be avoided.
- Comments SHOULD open with <!– and close with –>. Use of “–” or “>” within these delimiters SHOULD be avoided.
- Height and Width attributes in images SHOULD be restricted to cases where neither the image itself nor the ALT texts are essential to the document. In particular, images which are navigation icons SHOULD 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 SHOULD always be used.
- When using a floating image or table, “br clear” SHOULD if possible be used ahead of any further images or tables.
- When using HTML Tables, provision SHOULD be made to ensure the document is legible to browsers not supporting this feature.
- HTML containers (such as paragraphs or table cells) SHOULD be 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 SHOULD NOT depend on a particular browser window, font size or colour table to be readable. Indeed, they SHOULD NOT depend on any visual presentation whatsoever, except where the information content is inherently visual in nature.
- Authors SHOULD 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.
Note of course that none of these guidelines preclude visual enhancement of a document for those readers who are in a position to take advantage of an author’s intended presentation.
- Documents available in more than one language SHOULD be presented as parallel hierarchies in the languages concerned.
- HTTP content-negotiation MAY be used to determine the default language presented to the reader.
- Every document in a multilingual hierarchy SHOULD include links to the other languages available.
- Authors MAY use style sheets to enhance webpages, and are encouraged to do so when seeking to determine document appearance.
- Style sheets SHALL NOT be visible to browsers which do not support them. This SHALL be tested.
- Style sheets SHALL NOT be used in a manner detrimental to accessibility for browsers not supporting this feature.
- Frames MAY be 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 SHALL also be made accessible unframed via the NOFRAMES section.
- The NOFRAMES section SHOULD provide readers with a complete alternative. The use of a link to a separate version SHOULD be restricted to those occasions where it is large in (byte) size.
- Use of more than one frameset-based layout on a site SHOULD be avoided.
- All external links in a frameset page SHALL use the target attribute to avoid embedding another website in a frame.
- Script pages SHALL be inspected in browsers not supporting the scripting language (NOT merely browsers with this facility turned off) to ensure satisfactory appearance.
- Script pages SHALL be 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 SHALL be represented by sample outputs of the program. These sample pages SHALL be subject to the standards described for static documents. Every major path through the program SHALL be 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 the author’s control. Nevertheless, authors SHOULD seek to anticipate any potentially-disruptive input; for example, any HTML markup could be stripped.
- Authors SHALL in all cases ensure that user input cannot be used to compromise system security, or the accessibility of other information on the system.
Standards to be applied to the development of software associated with dynamic webpages are assumed to derive from existing PSS05 or equivalent standards where appropriate, and are outside the scope of this document.