Body Information

Copyright Information

Every web page has an implicit copyright, subject to the legal jurisdiction in which the work was created or claimed and any contractual arrangements between the developer and other interested parties. Every web page should include a specific copyright statement eliminating any ambiguity about this (which might be kept in metadata if the visible presentation is deemed objectionable). Even if the intention is to make material available in the public domain, the wording to be used should be reviewed with experts familiar with the relevant jurisdiction(s).

Web pages shall not knowingly include copyright-protected information without appropriate permission from the copyright holder.

Web pages should include a <link rights=...> entry (see Annex D).

Trademark Information

Web pages and websites may use trademarks that are the property of either the site owner or another party. These trademarks may be used within the scope of the site or used within the domain name, metadata, or a dynamic database that generates the web page. Because the international trademark system is both industry- and geographically-oriented, this inherently presents the potential for conflicts between website owners and trademark holders. Web pages should include information that helps resolve these conflicts. This could include metatags, explanations, and links to the appropriate information regarding the trademark owner.

Security Designations

In an intranet environment, pages should include an RMfield identified by the XML tag set <securitydesignationn> ... </securitydesignation> indicating the organizational security characteristic of the page content.

For HTML, use:

<span class="securitydesignation"> ...</span>

The exact wording will vary in different organizations, and may have legal implications (which will vary by country). Typical security "banners" include:

a) XYZ Corp. Confidential
b) Internal Use Only
c) Public Information

Be aware that pages without appropriate security designations may be implicitly public information (even though protected by copyright) or lacking in essential legal protections, depending on the legal jurisdictions from which they may be accessible. Be aware that the security designation will not assure automated enforcement of the security designation.

In an extranet environment, pages should include similar banners in a way that is consistent with the associated extranet community. Collaboration may permit sharing of confidential information, and such pages would carry corporate-specific banners; or collaboration may generate confidential information within the collaboration, and have designations specific to that arrangement.

Declaration of security designation should not be considered sufficient to provide security control. Site design should include evaluation of passwords, encryption, and other techniques to provide additional security controls.


A web page shall include a page date as an RMfield (<pagedate>, or <... class="pagedate">). This indicates the most recent date when a change considered being of value to the target-user communities has occurred.

A web page should include applicable dates from this list:

- Date of last modification, represented as an Mfield (<datemodified>, <... class="datemodified">). Changes in this date may occur without substantive changes in the content of the page. (Mfield is suggested since this date is considered only to be of use in page management, but not for target-user communities.) - Content date, represented as an Mfield or RMfield (<contentdate>, <... class="contentdate">), which is used to indicate that the content was current as of this date. This may not reflect changes in content from a previous content date. - Date of next content review, represented as an Mfield or RMfield (<nextupdate>, <... class="nextupdate">), is used to indicate when a review is scheduled. Substantive changes might occur prior to this date, and some form of user notification may be needed in certain business situations. - Content expiration date, represented as an Mfield or RMfield (<expirationdate>, <... class="expirationdate">), indicates that a web page should be deletable as of this date (which might be revised over time.) The value Archival may be used to indicate that the page contents are not expected to change; some form of persistent URL should be considered for archival pages where ongoing reference is expected.

Content expiration and/or content review dates should reflect the expected rate of change for the content. Website maintenance tools should use these dates. [These dates can be expected to be different from the cache expiration date, (see 5.2.)] See Annex C for examples of the above dates.

If the purpose of the above dates is for internal maintenance rather than use by the target-user community, it may be appropriate to maintain the information independently from the page content.

All dates, including the above, shall be presented with four digit years. Designers should use ISO  8601: 1988 [B14] format: YYYY-MM-DD (all digits) for dates. Dates should include time, and time-zone, such as one based upon Coordinated Universal Time (UTC), if this is relevant to the usage (HH:MM:SS, should be 24-hour format if machine-readable). If a time-zone designator is omitted, then local time of the website is assumed. Because local time in this context may be ambiguous, time-zone designators are recommended (UTC or UTC-offset) when indicating the time.

The recommended ISO 8601: 1988 [B14] time designation format is:

YYYY-MM-DDThh:mm:ssTZD where: YYYY is year MM is month (01ð12) DD is day (01ð31) The letter "T" is required if time is present hh is hour (00-23) mm is minute (00-59) ss is second (00-59) (decimal fractional extensions may be incorporated) TZD is time-zone designator value should be "Z" for UTC or +hh:mm for positive (east) displacement from UTC or -hh:mm for negative (west) displacement from UTC

This format should be used in any machine-readable fields.

The ISO 8601: 1988 [B14] date format is the preferred format by the HTML recommendations and by this standard. IETF RFC 1123: 1989 [B7] defines the format as exemplified by Sun, 06 Nov 1994 08:49:37 GMT, and this format is required by HTTP 1.1 in response fields.

Phone Numbers

All web pages containing telephone numbers shall provide sufficient context for use of the number. For sites with access across geographic boundaries, this includes country code, area code, time zone, and applicable hours. Toll-free numbers may not be accessible outside of the geographical area. With internal organizational networks, be aware of the potential need for contact by target-user communities who may only have access to external telephone lines (e.g., travel or telecommuting), or may need full prefix information between locations. Contact numbers shall be accessible for those who are visually impaired or deaf. Telephone numbers should be tagged using the HTML tag <phone> (an RMfield).


Icons can be international symbols or may be culturally dependent. Icons should be accompanied by text or alt attribute to provide for navigation by individuals who are not familiar with the icons used, individuals traversing the Web by text, and persons with visual/motion impairments. Icons may be selected from those defined in the ISO/IEC 11581 [B10], [B11], [B12], and [B13] specifications for international use. Icons may have trademark or legal implications as well.


Holidays vary between cultures and may even be specific to a particular locale. The web page should provide dates in universal formats (see 7.3) as well as any culturally-specific terms. The web page should not be designed on the premise that all users accessing the page will use the same time model as the page designers. Time-zone variations as well as "work day" variations should be considered in this context.

Place of Origin

To facilitate interaction with the target-user community, or for legal protection, it may be useful for the web page or site to indicate the country or place of origin. If country of origin is to be included, it should be an RMfield, or an Rfield and an Mfield (<origin>, <... class="origin">). This shall use the two-letter country code identifier from ISO 3166-1: 1997 for an RMfield or an Mfield. Web pages may include location designations (or exclusions) where these relate to specific legal jurisdictions.


Users in some browsers can designate human language preference. This information can be used to deliver information in the format appropriate to the user. Trade-offs between clarity of communication and the expense of maintaining pages in multiple languages should be considered in web page design. Automatic translation tools exist that provide a range of conversion to respond to target-user communities. Legal considerations also need to be incorporated into design here, with some countries requiring delivery of certain information in specific languages. When using a single language in a multi-cultural environment, the style and simplicity (including use of idioms and specialized terms) of the language should reflect the target-user community. Where translation is required, a verified translation may be needed.

Web pages shall declare their language of presentation using the lang attribute as appropriate. An example of use in the <HTML> tag is <html lang=en-US>, although the lang attribute can be inherited (including use in the span and div tags) for page segments with language changes. This shall be the native language of the web page.

The two letter codes identified in ISO 639: 1988 shall be used to indicate common languages, which may be followed by a hyphen and a two-letter (ISO 3166-1: 1997) country code to denote variants. (See HTML 4.0 specification, 8.1.1). The <dir> (direction) tag may also be needed to denote information for proper sequencing of presentation.

The lang attribute should be used by tools for both creation (e.g., spelling checkers, etc.) and presentation (e.g., speech synthesizers) where applicable.

For multiple language versions of a document, the link element with alternate, lang, and an appropriate URI may be used to indicate the URI for alternate-language versions. Also, the server may deliver alternate language versions based on site-specific conventions.


Some references are hemispherically oriented. Winter means something different in the northern hemisphere than it does in the southern hemisphere. Equating seasons to months should be avoided. Note that references such as "west" or "east" may be culture- or hemisphere-specific.

Units: metric, monetary

Outside of the United States, units of the modern metric system (SI Units) are the norm for measurement, and in most of the world they are a requirement for commerce. Web pages shall use measurement unit(s) applicable to their target-user communities, which should include metric in many cases.

Monetary units are nation-specific. Web pages should state monetary units in terms and currency symbols applicable to the context (both use of reference and intended user community). Some currency symbols are overloaded (such as "$") and require additional qualification based on the user community. The monetary units defined in ISO 4217: 1995 shall be used.

Legal Domains

Business practices vary between legal jurisdictions in addition to those ways indicated above. Comparative advertising, price quotations, intellectual property, or other forms of information may be regulated or prohibited in specific environments. Web page engineers should review the commercial limitations of the page contents with experts in these areas, as applicable. If advertising is accepted on a site, it shall be in keeping with the legal and ethical considerations of the user community.

Bandwidth Efficiencies

Analysis of the target-user community should include evaluation of the expected (and worst case) bandwidth. Web pages data elements shall be responsive to the business, information, or service objectives of the page. Tools for web page generation should not add extraneous information such as the name/version of the tool used.

It may be useful to have a web page size limit for a site, with warnings associated with links that lead to documents larger than the suggested size. Links to large items (e.g. pages, downloads, images, etc.) should have size information as an Rfield (<objectsize>, <... class="objectsize">) associated with the link.

It is especially desirable to have the initial point of contact (home page) for a site load quickly so users can identify the content of the site. This is especially true when some users have low bandwidth connectivity. For this reason, the home page should contain few and small graphic files, and all graphics should contain height/width tags and alt tags so that a user can see quickly what the content of the page will be.

Navigation Aids

A link shall be provided in each web page to get to one or more appropriate pages for more general information relevant to this site. The information pages should provide a context for users who may have entered from links or search results into the middle of the site. These pages may include information about the site or page owner. This should include a link to the site's home page and might also include owner organization, corporate department, physical location, etc.

Each page should provide information such as mailto link for author or other point of contact for users.

NOTE - Typically, this will not be "Webmaster@domain" as discussed previously.

Summaries and tables of contents of large documents should be available to allow for a quicker discard of uninteresting data/pages.

The use of the id attribute with HTML elements is encouraged to facilitate future links to specific elements of a document. This can be particularly useful when a series of pages have common structural elements. For example, standards have a "scope" section, and the use of <h1 id="scope"> facilitates future location of this section, and pointers to this section.

A URL pointing to a directory should either resolve to a default file (as set in the server), a useful directory listing (for the target-user communities), or have a clearly identifiable page for further information. The name of the default page for a directory access is defined in the server configuration. The default page should be named default.htm, index.html, or home.html. The primary navigation environment should be presented when the default name within a directory is used. The REDIRECT header tag can be used to manage navigation. Issues related to navigation by people with disabilities have to be considered (visual or motion impairments particularly).

Active Links

Periodic review is required to verify that all links are still active. Automatic review of links should help to quickly identify targets that are not valid anymore, but human review of links may be needed to ensure validity of content. Use of persistent URIs may help to avoid some of the problems created by these references. Links that go to pages with critical information should provide indication of the last verification date as an Mfield (<linkverified>, <... class="linkverified">).

Absolute and Relative Links

Links within a website should be relative to the linking page, and not to the site root. Sites may wish to establish a reference point for relative references (e.g. top-level directory) and use <BASE HREF= > to establish the reference point. Links to external websites should use persistent URIs, where available. Site pages intended for external reference should provide persistent URIs, where applicable. Digital Object Identifiers (DOI), as defined by the DOI Foundation (, may be useful as persistent URIs.


It may be useful to use cookies to maintain state between page accesses. In this case, the use of cookies shall be described and the user given an option of receiving these cookies as an explicit action. Web page sites that use cookies shall have a privacy statement available from their home page or general information page(s) that explains their use of cookies. Web page sites shall disclose if usage of prior site information is collected, and if information is shared with other organizations. If cookies are required and the required cookies are not received, the site shall provide relevant feedback to the user as an error message.

Frames and Encapsulation

If design includes the use of frames, then provision should be made for the user community to choose a no-frame implementation of the same content. This should be considered in the maintenance plan as well.

Frames shall not be used to mislead the user about the source, ownership or other aspects of frame contents. Frame presentation of 3rd party content shall only be done when full consideration is given to the copyright, presentation, appropriate commercial use, permissions and other legal and ethical aspects of such encapsulation.

Various methods can be used to encapsulate graphics or other page elements on a page that are transparent to the user.

NOTE - To avoid being "encapsulated" it may be appropriate to include a <base target="_top"> HEAD entry to force linked page(s) to acquire the full, original window.

Graphical Images

All graphic elements shall contain declared height/width display size, permitting the immediate allocation of page layout for these and concurrent rendering. The use of consistent style sheets can reduce page size, and provide for reuse of style for subsequent pages. Reuse of images, as opposed to use of new images, can reduce download time by taking advantage of local caching.

Multiple graphic images at the server should be considered, providing for lower bandwidth connections, and/or user choice. A potential convention is to have a "thumbnail" graphic delivered, which is also a link to a higher resolution graphic as an option for the user community.

Where a server may deliver images in multiple formats, image URLs should not include a specific format name structure (e.g. xxx.gif). To allow for content negotiation with users and to minimize overhead in response, a diverse set of image formats should be provided.

Images should not be used to bypass HTML limitations or provide "style" control. Where available, CSS should be used. Images shall not be used to present text in an alternative style. This is disruptive to text-only browsers, it limits accessibility and global applicability, and it has a negative impact on performance. Graphic presentation of written materials for certain languages, cultures, or disciplines may be necessary.

Sites should support image formats for JPEG, PNG, and GIF for compatibility, and seek to deliver the least overhead image acceptable to the client. For animated images, Network Motion Graphics (NMG) should be supported, and scripting or client-side executable languages may be more efficient means of providing the required functionality.

Unfortunately, firewalls and gateways can convert data types. Hence, the client may not receive the expected graphic.

Deprecated HTML Elements and Attributes

HTML version 4.0 identifies a set of style specific tags as deprecated (usage discouraged). These include <blink>, <font>, <b>, <i>, <u>, <strike>, <s>, <basefont>, <center>, <menu>, <listing>, <plaintext>, <XMP>, and color attributes (e.g., background, text, link, vlink, alink, etc.). Where the client design allows, the web page should not use the deprecated tags to control formatting, but should use style sheets instead.

Physical Location Information

Physical addresses should be aligned with desired usage. Full postal designation (with country) for mail and delivery services may require a street address. In addition, links to appropriate maps may be useful.

To facilitate indexing by physical location, a web page may include the RMfields <span class="longitude"> ... </span><span class="latitude"> ... </span>, and for addresses specifying a street location, the RMfield <span class="crossstreet"> ... </span>. Cross street can be useful for fine-tuning in human navigation and for fine-tuning in mapping software.

Any website offering or effecting commercial transactions shall prominently display postal addresses and telephone numbers for follow-up inquiries.

Server Technology Independence

Depending on the target audience and the desired sophistication of the pages, a web page may or may not make use of server side capabilities such as SSI, ASP, or other capabilities. It is desirable, whenever possible, to produce pages that do not depend on server settings or capabilities. Two recommendations in this area include:

a) Never point to a directory in a relative reference. Instead point to the file within the directory.

For example <a HREF="detail/"> should be <a HREF="detail/index.htm>". Because the "default file" may vary from server to server, pages which reference directories may not be portable from one server to another.

b) Whenever important elements such as navigation elements are provided through server

support, also provide these navigation controls directly, perhaps through a text menu at the bottom of the page. Because more server code is treated as comments by browsers, these pages will be usable across a wide range of servers even though their appearance may change.

The ultimate goal is to allow pages, whenever possible, to be moved from server to server, and even be moved onto CD-ROM for distribution without suffering from broken links.

Version 2.0
Page last modified: 15 May 2002
National Institute of Standards and Technology (NIST)