Standards for HTML Authoring for the World Wide Web
The purpose of these standards is to encourage compliance with Standards
and Good Practice in Web Authoring, and to ensure that authors who
deviate from such standards are aware of the consequences of their actions.
In particular, it is intended to ensure that systems developed for the
World Wide Web are accessible to all users, regardless of their Client
software configuration. These Web Authoring standards should be seen
as complementary to the HTML Markup standards published by W3C.
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 Organisation and specific external partners ("Intranet").
Professional Web developers working for or on behalf of any organisation
whose business is not the Web itself (i.e. anyone working in an environment
where you might reasonably be expected to know more than your Employer or
It is assumed that readers already have a general working knowledge of HTML,
such as might be acquired through appropriate training or experience.
Definitions, Acronyms and Abbreviations
Following PSS-05, the following Standard Practices are 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.
The following acronyms will be familiar to readers, but are listed
here for completeness:
- The Common Gateway Interface
- Cascading Style Sheets
- HyperText Markup Language
- HyperText Transfer Protocol
- Standard General Markup Language
- The World-Wide Web Consortium
- The World-Wide Web
- ESA PSS-05 Software Engineering Standards Issue 2, February 1991.
- HyperText Markup Language
- WDG HTML
This document presents requirements as a simple list,
under the following general headings:
- HTML Headers
- Colours and Background Images
- Appropriate Use and Deprecated Tags
- Nonstandard/Proprietary Markup
- Browser Compatibility
- International Pages
- Style Sheets
- Frames Pages
- Client-side Scripts
- Dynamic Pages
Web Authoring Standards
- 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
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:
Other documents MAY include such headers.
- KEYWORDS and DESCRIPTION meta elements for the benefit of Web indexers.
- A "REV=MADE" link indicating the document's author or maintainer.
- 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
- 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
- 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.
- Images SHOULD use height and width attributes, except as noted
under Browser Compatibility below.
- <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
- 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
> 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
- 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, "
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
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.
provided it does not detract from the page's accessibility to
browsers not supporting or enabling this feature.
- 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
- 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.
Copyright © 1997. All rights reserved.