[ contents ]

W3C

Authoring Techniques for XHTML & HTML Internationalization: Specifying the language of content 1.0

W3C Working Draft 15 October 2004

This version:
http://www.w3.org/TR/2004/WD-i18n-html-tech-lang-20041015/
Latest version:
http://www.w3.org/TR/i18n-html-tech-lang/
Previous version:
http://www.w3.org/TR/2004/WD-i18n-html-tech-lang-20040509/
Editor:
Richard Ishida, W3C

Abstract

Specifying the language of content is useful for a wide number of applications, from linguistically sensitive searching to applying language-specific display properties. In some cases the full application is still awaiting full development, whereas in others, such as detection of language by voice browsers, it is a necessity today. Marking up language meta information is something that can and should be done today. Without it, none of these applications can be taken advantage of.

This document is one of a series of documents providing HTML authors with techniques for developing internationalized HTML using XHTML 1.0 or HTML 4.01, supported by CSS1, CSS2 and some aspects of CSS3. It focuses specifically on advice about specifying the language of content. It is produced by the Guidelines, Education & Outreach Task Force (GEO) of the W3C Internationalization Working Group (I18N WG). With this version, the GEO Task Force is seeking feedback about the content of this document prior to converting it to Working Group Note status.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a new Working Draft of a document produced by the GEO (Guidelines, Education & Outreach) Task Force of the W3C Internationalization Working Group (I18N WG). The Internationalization Working Group is part of the W3C Internationalization Activity. This is a draft document that may not fully represent the consensus of the group at this time. The Working Group expects to advance this Working Draft to Working Group Note

The document provides practical techniques related to specifying the language of content that HTML content authors can use to ensure that their HTML is easily adaptable for an international audience. These are techniques that are best addressed from the start of content development if unnecessary costs and resource issues are to be avoided later on.

A new version of the Working Draft has been published at this time to enable wide review and feedback before moving the document to Working Group Note status.

The Task Force encourages feedback about the content of this document (as well as participation in the development of the techniques by people who have experience creating Web content that conforms to internationalization needs). Send comments about this document to www-i18n-comments@w3.org. The archives for this list are publicly available.

The Internationalization Working Group will not allow early implementation to constrain its ability to make changes to this specification prior to final release. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy. At the time of publication, the Working Group believed there were no patent disclosures relevant to this specification.

Table of Contents

Appendices

A Acknowledgements
B References

Return to top of contents...1 Introduction

Return to top of contents...1.2 How to use this document

This document is one of several documents relating to the design of XHTML and HTML documents.

If you are new to this topic you may wish to read this document from end to end. It is, however, expected that this document will normally be used for reference purposes - the reader dipping in to a particular section to find out how to perform a specific task with internationalization in mind.

An overview document is available that summarises all the recommendations of this and its companion documents together, organized according to tasks that a developer of XHMTL/HTML content may want to perform. When this material is used as a reference, it is recommended that the overview document is used as a starting point.

Cross references and additional resources are summarized at the end of each technique.

Editorial notes have been left in this version of the document. [Ed. note: These are marked like this].

For information about the applicability of recommendations to user agents see below.

Return to top of contents...1.3 Standards addressed

This document provides techniques for developing pages using HTML 4.01, XHTML 1.0 and XHTML 1.1 with CSS1, CSS2 and some parts of CSS3.

Note that XHTML source can be served as XML (using MIME types application/xhtml+xml, application/xml or text/xml) or HTML (using the MIME type text/html).

It is very common for XHTML to be served as HTML, following the compatibility guidelines in Appendix C of the XHTML 1.0 specification. This allows authors with the right editing tools to produce valid XML code, which therefore lends itself to processing with such things as scripting or XSLT, but is also well supported for display by most mainstream browsers. (XHTML served as application/xhtml+xml is not well supported for browser display at the moment.) In this document we wish to reflect practical reality for content authors, so we cover XHTML served as text/html in the techniques.

Indeed we encourage the use of XHTML, and all the examples (unless trying to make a specific point about HTML 4.01) are written in XHTML.

For XHTML served as XML, this document limits its advice to documents served as application/xhtml+xml. Note that user agent support for XHTML served as XML is still patchy.

Return to top of contents...1.4 User agents addressed

In order to improve the value of this information to the user we try to ground techniques with information about their applicability to particular user agents. User agents, in the current version of this document, means a number of mainstream browsers. (The scope may grow as resources and test results become available for other user agents.)

In an attempt to make the task of tracking browser applicability manageable, we have chosen a 'base version' for each of the user agents we are tracking. This base version represents a fairly recent, standards-compliant version of the browser, but nontheless a version that we might expect many people to be using. Where a browser operates in both standards- and quirks-mode, standards-mode is assumed (ie. you should use a DOCTYPE statement).

The base versions considered for this version of the document include:

We will also assess the applicability of the techniques against the latest version of the user agent at the time of publication. This will indicate progress made since the base versions. For this version of this document, that means: [Ed. note: Some testing remains to be done.]

Generally, the techniques described will be applicable for immediate use. However we may also recommend things that are not yet widely supported, but are described by the standards, and hopefully will be supported given a little time. Where issues of this kind exist, or other issues related to user agent support, these will be flagged by small graphics immediately after the technique summary:

We will then generally describe the issues in the detail that follows.

Summaries for such techniques will also be worded more cautiously. For example, "Consider doing X".

If more testing is needed to ascertain applicability, the user agent name will be followed by a question mark.

Detailed information may also be provided from time to time about behavior of a user agent in another version than the base or current versions.

Return to top of contents...2 Definitions

Primary language

The primary language describes the language of the document as a whole.

It does not describe every language used in a document. Many documents on the Web contain embedded fragments of content in different languages, however, the page is typically still aimed at speakers of one particular language. For example, a German city-guide for Beijing may contain useful phrases in Chinese, but the primary language of the page is German, ie. it is aimed at a German-speaking audience.

It is also possible to imagine an occasional situation where a document contains the same or parallel content in more than one language. For example, it may be a Web page that welcomes Canadian readers with French content in the left column, and the same content in English in the right hand column. Here the document is equally targeted at speakers of both languages, and in this case there are two primary languages. (This situation is not as common on the Web as in printed material since it is easy to link to separate pages on the Web for different audiences).

Primary language is metadata about the document as a whole. Such metadata may be used for searching, serving the right language version, classification, etc. It is not specific enough to indicate the language of a particular run of text in the document for text processing - for example, in a way that would be needed for the application of text-to-speech, styling, automatic font assignment, etc.

(Note that there exist pages where the navigational information, including the page title, is in one language but the content of the page is in another. While this is not necessarily good practise, it may be valid to claim that the primary language of the page was that of the content - ie. the language of the readership group the page was aimed at - rather than the language at the top of the document source. We will not attempt to define here what constitutes a primary language in terms of document structure - such decisions will be left to the reader.)

Primary language metadata is usually best declared outside the document in the HTTP Content-Language header, although there may be situations where an internal declaration using the meta element may be appropriate.

Text processing language

When specifying the text processing language you are declaring the language in which a particular range of text is actually written, so that user agents or applications that manipulate the text, such as voice browsers, spell checkers, or style processors can effectively handle the text in question. So we are, by necessity, talking about associating a single language with a specific range of text.

The text processing language is usually best declared using attributes on elements. Enclosed elements inherit the declared value, but you can, of course, override an initial declaration by specifying a different language on embedded elements where the language changes, eg. a French word in an English paragraph.

The default text processing language is not necessarily the same as metadata about the primary language of a document.

Return to top of contents...3 Declaring the language of a page

For a discussion of why it is important to declare language information in a document see the article Why use the language attribute? and the beginning of the tutorial Using Language Information in XHTML, HTML and CSS.

See also the following section dealing with the special case where there are more than one primary languages.

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

Declaring the text processing language in the html tag sets the default text processing language for the whole document. It can be overridden for portions of the document as required.

You should always declare the text processing language of the page using the lang and/or xml:lang attributes. This is already important for applications such as accessibility and searching, but many other possible applications for this information may develop over time.

The following example declares an HTML document to be in Canadian French:

Example:

<html lang="fr-CA">

Note that language declarations in the HTTP header or the Content-Language meta tag should be used to describe the primary language, ie. metadata about the document as a whole, rather than the default text processing language. Most documents have one primary language, but where there are more it may not be necessary to declare a single default text processing language in the html tag. The relevance will depend on the structure used for the document.

For details of which language attribute to use, and how to use language codes use, see section 6 Specifying language.

For a comparison of 'primary language' and 'text processing language', see section 2 Definitions.

Resources:

Background information

How to's

Sources

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

The Content-Language declaration, whether it is used in the HTTP header or a meta tag, can be useful for expressing metadata about the primary language(s) of the document being served.

Content-Language information sent in the HTTP header is defined on the server.

The following example shows how the language would be declared in a meta tag inside a document:

Example:

<meta http-equiv="Content-Language" content="en"/>

Note that this is different from expressing the default language of content for text processing, which must be done using a language attribute on the html tag.

The extent to which metadata information in the HTTP header or a meta tag is used by applications, or which of the two is preferred is not clear at this point.

There are potential issues surrounding use of the HTTP Content-Language header related to the maintenance and use of server-side information. Many authors may find it difficult to access server settings, particularly when dealing with an ISP. Also, pages may not always be located on servers. So this approach is not a solution that is always available.

For a comparison of 'primary language' and 'text processing language', see section 2 Definitions.

Resources:

Background information

Sources

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

There is generally a lot of confusion about the difference between declaring language information using Content-Language in HTTP or meta elements, and using language attributes. In particular, much of the informal advice on the Web about how to declare the language of the document tells you to use the a meta tag to declare the language of the document. At least one popular authoring tool automatically inserts into the meta element language information that you declare in the page properties dialog box. Unfortunately, we have yet to identify any user agent or application that recognizes information declared in this way, whereas language information declared in the html tag is consistently recognized.

Techniques in this document recommend that Content-Language be used for describing primary language metadata, and that attributes be used for describing the default text processing language of the document. (In fact, this question only arises when describing the language of a document at the highest level, since the language of embedded fragments in a document can only be expressed using attributes.)

Because the language attribute can only declare a single language at a time, it is a poor candidate for describing documents with multiple primary languages. Content-Language declarations, however, can declare a list of languages.

On the other hand, Content-Language declarations are not specific enough for declaring the text processing language, and it is strangely inconsistent not to use attributes to declare the default text processing language when they have to be used for embedded text.

In addition, as mentioned above, from a practical perspective the information contained in HTTP Content-Language headers is rarely used by mainstream browsers for identifying the default processing language, and such implementation as there is is inconsistent. The information in the meta tag is typically not recognized at all by current user agents in a processing context.

For a fuller discussion on this topic, see Using HTTP and meta for language information.

For a shorter comparison of 'primary language' and 'text processing language', see section 2 Definitions.

Resources:

Background information

Sources

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

The body tag is the wrong place to express this information because it only refers to a portion of the text in the document. For example, the text in the title element is natural language text that should also inherit the language information. If language is declared in the body element, however, this is not the case.

The html element is the highest level element in the document, and is therefore most appropriate for declaring the default text processing language of the document. All elements within the document will inherit that value.

Return to top of contents...4 Documents with more than one primary language

It is not common to find pages on the Web with more than one primary language. One reason is that it is easy to link to alternative pages instead. In addition, there may be differing views on what kind of document structure reflects a document with multiple primary languages.

For a discussion of why it is important to declare the language of a document see the article Why use the language attribute? and the beginning of the tutorial Using Language Information in XHTML, HTML and CSS.

See the previous section for techniques related to the general case, ie. a single primary language.

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

The HTTP specification provides for more than one language to be expressed as the value of the Content-Language header.

The following example declares a document to have three primary languages: German, French and Italian:

Example:

Content-Language: de,fr,it

The meta element provides a similar possibility:

Example:

<meta http-equiv="Content-Language" content="de,fr,it"/>

Resources:

Sources

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

Remember that the language attribute on the html tag should be used to declare the default text processing language for the document. Given that only one language can be defined at a time as the text processing language, there may appear to be little point in using an attribute on the html if all primary languages are used in a completely unbiased way in the document.

If, however, the page header information or navigation is in one particular language, or there is a bias of some other kind towards one particular language, you may want to use a language attribute on the html tag.

Note that there is a definite problem when dealing with multilingual title elements. Only one language can be declared for this element in HTML 4.01, since the only content allowed is character data.

[Ed. note: Should we mention the use of 'mul' as a language code? If we do, should we recommend it or not?]

For details of how to use language attributes, see the section 6 Specifying language.

Resources:

Background information

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

Dividing parallel text at the highest possible level, can simplify the process of guiding users to the text via searching, links, etc. It also reduces the work of labelling the language of document fragments.

For details of how to use language attributes, see the section 6 Specifying language.

Resources:

Background information

Return to top of contents...5 Declaring language changes in a page

For a discussion of why it is important to declare the language of a document see the article Why use the language attribute? and the beginning of the tutorial Using Language Information in XHTML, HTML and CSS.

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

Where the language of the text is different from the language declared in the html tag, you should indicate this using the lang or xml:lang attributes. For example, in HTML you would write:

Example:

<p>The French for <em>Cat</em> is <em lang="fr">chat</em>.</p>

The lang attribute can be used on all HTML elements except applet, base, basefont, br, frame, frameset, iframe, param and script. (Note, by the way, that this means that you could use language attributes on things like bitmaps and audio files that are language specific. Such information may be particularly useful for script-based processing of documents.)

If there is no markup around the text in a different language, use a span element to delimit the boundaries. Here is an example in XHTML 1.0 served as text/html:

Example:

<p>The title in Chinese is <span lang="zh-Hans" xml:lang="zh-Hans">中国科学院文献情报中心</span>.</p>

For details of which language attribute to use, and how to use language codes use, see section 6 Specifying language.

Resources:

Background information

How to's

Sources

Return to top of contents...6 Specifying language

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

When serving HTML you should use the lang attribute to declare the language of the document or a range of text. For example, the following declares a document to be in Canadian French:

Example:

<html lang="fr-CA">

When serving XHTML as text/html, you should use both the lang attribute and the xml:lang attribute. The xml:lang attribute is the standard way to identify language information in XML. The following shows how you would mark up the previous example for XHTML 1.0 served as text/html.

Example:

<html lang="fr-CA" xml:lang="fr-CA" >

The xml:lang attribute is not actually useful for handling the file as HTML, but takes over from the lang attribute any time you treat the document as XML for, say, scripting or validation.

If you are serving XHTML 1.0 pages as XML (ie. using a MIME type such as application/xhtml+xml), or serving pages as XHTML 1.1, you do not need the lang attribute, since lang is part of the HTML language. The xml:lang attribute alone will suffice.

Example:

<html xml:lang="fr-CA" >

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

RFC 3066 is the IETF document that defines how to use language tags to identify languages. It obsoletes the RFC 1766 referred to by earlier specifications.

RFC 3066 merely expands and clarifies the possibilities for specifying languages. If you have been using RFC 1766 you should not need to make any changes to your code in order to start using RFC 3066.

NOTE: The HTML specification still recommends the use of RFC 1766 for identifying language. RFC 3066 is an update of RFC 1766 that supersedes it, and there is a planned erratum in place for the HTML specification, so you should use RFC 3066 despite what the HTML specification currently says.

A proposed successor to RFC 3066 is currently being developed, but it aims to retain backwards compatibility with tags created using RFC 3066.

Note also that you can only specify one language or language variant per element.

For an introduction to the RFC3066 rules for language codes, see Specifying language attribute values in the tutorial Using Language Information in XHTML, HTML and CSS.

Resources:

Background information

How to's

Sources

UA applicability issues:   IE(Win)  No issues  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari  No issues  IE(Mac)  No issues 

RFC3066 specifies that the two letter codes should be used where available, since this aids interoperability by ensuring that a single code is used everywhere to refer to a particular language.

This also avoids the question of which 3-letter code to use for those languages that have two 3-letter codes, since all such languages have a 2-letter code also.

Resources:

How to's

Sources

UA applicability issues:   IE(Win)  Issues still to date  Firefox  Issues with base version, but not latest  Mozilla  Issues still to date  Opera  No issues  NNav  Issues still to date  Safari    ?   IE(Mac)    ?  

RFC3066 specifies how to identify a language. Simplified vs. Traditional Chinese is a distinction based on script. In the past zh-CN (Chinese spoken in Mainland China) was commonly used to label Simplified Chinese, and zh-TW (Chinese spoken in Taiwan) was commonly used for Traditional Chinese. Apart from the fact that this is mislabelled, you could not guarantee that others would recognize these conventions, or even follow them. For example, some people used zh-HK to represent Traditional Chinese.

Now the IANA registry makes available the codes zh-Hans and zh-Hant for Simplified and Traditional Chinese, respectively. The following two examples illustrate the use of these tags.

Example:

Simplified Chinese:

<p lang="zh-Hans" xml:lang="zh-Hans">当世界需要沟通时,请用统一码!</p>

Example:

Traditional Chinese:

<p lang="zh-Hant" xml:lang="zh-Hant">當世界需要溝通時,請用統一碼!</p>

It is expected that these tags will persist for the foreseeable future, so on the one hand it would be good to use them as soon as possible in order to improve interoperability sooner rather than later.

On the other hand, you need to assess the impact of changing the tags. This is not really an issue for self-describing usage, such as with :lang for application of language-based styling. It may be more of an issue where external applications are looking for tags related to Chinese but are unaware of the zh-Hans and zh-Hant variants.

There is one particular area where this may be an issue for the display of text on a user agent. Some (but not all) user agents use language information to automatically choose a font for CJK ideographic text (see the test page). Note that this assumes that (a) you have appropriate fonts set in your preferences, that (b) the document styling does not apply a font, and that (c) the user agent supports this behaviour (not all do). The following table summarizes support for this feature in baseline user agents:

IE 6.0Does not recognise either of these codes.
Firefox 1.0PRHandles both codes correctly.
Mozilla 1.7.2Recognizes the tags but treats them both as Simplified Chinese.
Netscape 7.0Recognizes the tags but treats them both as Simplified Chinese.
Opera 7.54Doesn't automatically apply fonts in this fashion, so is irrelevant.
Resources:

How to's

Test data

Return to top of contents...7 Specifying the language of a link destination

UA applicability issues:   IE(Win)  Issues still to date  Firefox  No issues  Mozilla  No issues  Opera  No issues  NNav  No issues  Safari    ?   IE(Mac)    ?  

The hreflang attribute on an a element indicates the language of the document at the other end of the link. In practise, hreflang is typically not used by mainstream browsers. Besides that it is much better to ensure that the target document uses the language attribute in the html tag, so that this information is not needed.

A common alternative use for this attribute is to generate a visible marker attached to link text that indicates the language of the destination page for the reader. The idea is to allow the reader to decide in advance whether or not to follow the link, according to their language skill. If the user has to waste time following the link to find out that they cannot read the target document this introduces fatigue, and lack of confidence when faced with links that do go to readable pages.

The approach relies on CSS selectors that detect the value of the hreflang attribute and use the CSS content property to display an indicator of the language.

For example, the following link points to a page in Swedish.

Example:

There is also a translated page describing why a DOCTYPE is useful [sv].

The code to enable this in CSS may be something like:

Example:

a[hreflang]:after { content: " [" attr(hreflang) "] "; }

The markup would read as follows:

Example:

<p>There is also a translated page describing <a href="swedish-doc.html" hreflang="sv">why a DOCTYPE is useful</a>.</p>

This says: for each a element with an hreflang attribute, add the value of that attribute in square parentheses after the link.

There are, however, potential problems with this approach.

Firstly, not all user agents support the CSS required to enable it (see the test). Internet Explorer does not support :after.

Secondly, a newly translated version may become available. Assume, for example that a French page has used this approach some time ago to point to the Apache documentation, which at that time was only in English. Later, the Apache documentation is translated into French and language negotiation is put in place. Unless the French page referred to earlier is updated, it will now be incorrectly warning French readers that the Apache documentation is in English, and possibly discouraging them from following a link to what is actually a perfectly legible document.

Thirdly, if a resource is available in multiple languages (say you are linking from an English overview to detailed descriptions that are available in multiple languages) it is not possible to express that, since the hreflang attribute accepts only a single language as its value.

Resources:

How to's

Sources

Test data

UA applicability issues:   IE(Win)  Issues still to date  Firefox  No issues  Mozilla  No issues  Opera    ?   NNav  No issues  Safari    ?   IE(Mac)    ?  

Flags represent countries, not languages. There are many countries that use the same language, and numerous countries that have more than one official language.

A much better approach is to generate some text. In the previous technique, an example is shown that uses the actual attribute value, since these two-letter codes are typically recognisable by speakers of the language.

Return to top of contents...A Acknowledgements

The following GEO Task Force members have contributed their time and valuable comments to shaping these guidelines:

Phil Arko (Siemens), Steve Billings, Deborah Cawkwell (BBC World Service), Wendy Chisholm (W3C WAI), Andrew Cunningham (State Library of Victoria), Martin Dürst (W3C), Lloyd Honomichl, Susan K. Miller (Boeing), Russ Rolfe (Microsoft), Peter Sigrist, Tex Texin (XenCraft), Najib Tounsi (Ecole Mohammadia d'Ingénieurs)

Return to top of contents...B References

CSS2.1
Håkon Wium Lie, Bert Bos, Tantek Çelik, Ian Hickson, Eds., Cascading Style Sheets, level 2 revision 1, Candidate Recommendation, W3C Recommendation. (See http://www.w3.org/TR/2004/CR-CSS21-20040225.)
HTML 4.01
Dave Raggett, Arnaud Le Hors, Ian Jacobs, Eds., HTML 4.01 Specification, W3C Recommendation. (See http://www.w3.org/TR/html401.)
RFC2616
R. Fielding et al., Hypertext Transfer Protocol -- HTTP/1.1, January 2001. (See http://www.ietf.org/rfc/rfc2616.txt
RFC3066
H. Alvestrand, Tags for the Identification of Languages, June 1999. (See http://www.ietf.org/rfc/rfc3066.txt
WCAG 1.0
W. Chisholm, G. Vanderheiden, I. Jacobs, Web Content Accessibility Guidelines 1.0, May 1999. (See http://www.w3.org/TR/WCAG10/)
WCAG-HTML 1.0
W. Chisholm, G. Vanderheiden, I. Jacobs, HTML Techniques for Web Content Accessibility Guidelines 1.0, November 2000. (See http://www.w3.org/TR/WCAG10-HTML-TECHS/)
XHTML 1.0
W3C HTML Working Group, XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition), W3C Recommendation. (See http://www.w3.org/TR/xhtml1/.)
XML 1.0
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Eds., Extensible Markup Language (XML) 1.0, W3C Recommendation. (See http://www.w3.org/TR/REC-xml.)