W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1999

Guideline 2.1 - rationale and techniques

From: Charles McCathieNevile <charles@w3.org>
Date: Fri, 26 Feb 1999 11:01:23 -0500 (EST)
To: WAI AU Guidelines <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.04.9902261023550.21555-100000@tux.w3.org>
An attempt to expand on Jan's explanation of the rationale, and to add
some techniques for the section 2.1 checkpoints:

Jan had written:
My thoughts on new text for 2.1 and 2.2 are the following:
2.1 Generate standard markup
The first step towards accessibility is full compliance with standards.
Observation of standards permits interoperability, whereby documents and
content may be displayed by a wide variety of technologies. (ed. needs

I would say the following: The first step towards accessibility of web
content is interoperable document types. Without reference to a document
type (or format), user agents cannot reliably represent the semantics
inherent in the markup in a way which is meaningful. Adherence to the
claimed document type is also necessary. Where a document type is extended
in some way, to provide new functionality, it is important that it not
interfere with accessiblity requirements. Otherwise, special purpose user
agents and assistive technologies in particular may not be able to render
important information for users.

   2.1.1: [Priority 1]
          Ensure that content is created in accordance with W3C
recommendations or other published standards.
   2.1.2: [Priority 1]
          Validate, and where necessary allow the author to correct,
markup which is imported from another source.
For HTML 4.0 and CSS there are validation tools available via the web. The
software is also available under the standard W3C copyright, which allows
for adapatation and incorporation into other products royalty-free.
Correction of invalid markup can sometimes be done automatically (for
example, importing HTML markup to an XML document may require changes of
case and addition of closing tags, according to well-defined rules). In
some cases, the tool may either force semantic changes, or ask the user to
clarify substructures. 
An HTML example would be the use of LI elements outside a list, where the
tool may prompt the user to define which items are encompassed within
lists, and how many lists are present.

   2.1.3: [Priority 2]
          Use W3C recommendations where possible.

W3C recommendations are produced subject to a review for accessibility and
for interoperability. The use of available W3C recommendations should
provide best-practise in both these critical areas, whereas other
languages or protocols may not support these two principles.
The latest version of a W3C Recommendation is the best version to use,
since backward-compatibility is required as part of inter-operability, and
accessiblity must be the same or better in each subsequent version.
   2.1.4: [Priority 1]
          Do not use a document type which precludes users' access to
content or function of the document.
New document types are constantly being developed, and in many cases offer
improvements to the structure and utility of web content. In implementing
a new or extended document type it is important to ensure that a tool is
not removing access to information which had been inherent in the base
document type. 
An example of a document type which contravenes this checkpoint is a
FRAMESET (link to w3c frameset.dtd) used without NOFRAMES - it precludes
access to the underlying information, whereas NOFRAMES provides a means to
access the information contained within the FRAMESET.


Charles McCathieNevile

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://purl.oclc.org/net/charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
Received on Friday, 26 February 1999 11:01:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC