HTML AUTHORING STANDARDS

The purpose of the following is to encourage compliance with existing standards and general good practice in HTML authoring, and to ensure that authors who deviate from such standards are aware of the consequences of their actions.

In particular, these standards are intended to ensure that systems developed for the World Wide Web are accessible to all users, regardless of the client configuration. Additionally, these standards shall apply to all webpages created to be accessible to the general public, except as follows:

• 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 organization and specific external partners ("Intranet, Extranet").

It is assumed that readers have a working knowledge of HTML.

Definitions, Acronyms and Abbreviations

Standard Practices - Defined:

 

Mandatory Practices

Sentences containing the word SHALL are mandatory practices, and must be followed without exception in all Web pages and systems. The word MUST is used in statements that repeat a mandatory practice.

 

Recommended Practices

Sentences containing the word SHOULD are strongly recommended practices. A justification may be required if they are not followed.

 

Guideline Practices

Sentences containing the word MAY are guidelines. No justification is required if they are not followed.

Acronyms

 

CGI

Common Gateway Interface

 

CSS

Cascading Style Sheets

 

HTML

HyperText Markup Language

 

HTTP

HyperText Transfer Protocol

 

SGML

Standard General Markup Language

 

W3C

The World-Wide Web Consortium

 

WWW

The World-Wide Web

Overview

This document presents requirements as an outline under the following headings:

1. Validation
2. HTML Headers
3. Colors and Background Images
4. Images
5. Appropriate Use and Deprecated Tags
6. Nonstandard/Proprietary Markup
7. Browser Compatibility
8. International Pages
9. Style Sheets
10. Frames Pages
11. Client-side Scripts
12. Dynamic Pages

Web Authoring Standards

Validation

1. All HTML documents SHALL be checked with an HTML validator.
2. Documents SHOULD be validated at HTML level 2.0, 3.2 (Wilbur), or future specifications from W3C when available.
3. 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 (e.g. those available from WebTechs validation service), the DTD itself SHALL be referenced in a comment within the document.
4. HTML documents SHOULD validate successfully.
5. 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.

HTML Headers

1. All HTML documents SHALL include an appropriate TITLE
2. Documents MAY include other header elements, such as relational links, Stylesheets, Client-side scripts, and META elements.
3. 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.

Colors and Background Images

1. Authors MAY use any legal markup to determine document colors, but SHOULD use RGB specifications to do so.
2. Where colors are set by an author, they SHALL ensure a strong contrast between text and background. This implies light-on-dark or dark-on-light: color 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.
   
3. Background images (where used) SHOULD be small, and SHOULD be of a similar colour to the BGCOLOR specified.
4. Conspicuous background images SHOULD be avoided in pages containing textual information.

Images

1. 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.
2. All images SHALL have ALT texts. Where appropriate, ALT=" " is acceptable.
3. 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.
4. ALT texts SHOULD NOT duplicate nearby document text.
5. 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).
6. ALT texts for imagemaps MAY direct readers to a separate text toolbar; otherwise they SHOULD be blank (ALT=" ").
7. Where imagemaps are used, alternative means of navigation SHALL be made available to readers.
8. Images SHOULD use height and width attributes, except as noted under Browser Compatibility below.

Appropriate Use and Deprecated Tags

1. <BLINK> SHALL NOT be used.
2. <FONT> SHALL NOT be used in place of HTML headers <H1> - <H6>
3. 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.
4. <H1>...</H1> SHOULD be used exactly once in an HTML page.

Nonstandard/Proprietary Markup

General standards: particular cases are dealt with separately below.

1. Subject to the validation standards above, authors MAY use nonstandard or proprietary tags in an HTML document.
2. 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".
3. Undefined Entities SHALL NOT be used.

Browser Compatibility

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.

1. Use of < or > within a tag, in a construct such as <IMG SRC="forward.gif" ALT="=>"> risks breaking parsers and SHOULD be avoided.
2. Comments SHOULD open with <!-- and close with -->. Use of "--" or ">" within these delimiters SHOULD be avoided.
3. 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.
4. When specifying document colors in a BODY tag, numeric RGB notation SHOULD always be used.
5. When using a floating image or table, "br clear" SHOULD if possible be used ahead of any further images or tables.
6. When using HTML Tables, provision SHOULD be made to ensure the document is legible to browsers not supporting this feature.
7. 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.

1. Pages SHOULD NOT depend on a particular browser window, font size or color table to be readable. Indeed, they SHOULD NOT depend on any visual presentation whatsoever, except where the information content is inherently visual in nature.
2. 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.

International Pages

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

Style Sheets

1. Authors MAY use style sheets to enhance WebPages, and are encouraged to do so when seeking to determine document appearance.
2. Style sheets SHALL NOT be visible to browsers which do not support them. This SHALL be tested.
3. Style sheets SHALL NOT be used in a manner detrimental to accessibility for browsers not supporting this feature.

Frames Pages

1. 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.
2. Information provided via a frameset SHALL also be made accessible unframed via the NOFRAMES section.
3. 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.
4. Use of more than one frameset-based layout on a site SHOULD be avoided.
5. All external links in a frameset page SHALL use the target attribute to avoid embedding another website in a frame.

Client-Side Scripting

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

Dynamic Pages

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.

1. 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.
2. 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.
3. 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.