section 2.5 - charles' proposal

NB: I use the abbreviation DTD here to mean a formal declaration of a
document's syntax, which may be by a DOCTYPE declaration (as in HTML 4.0),
by the use of XML namespaces, or by some other technique.

The four important ideas we want in section 2.4 are:

1. Any accessiblity features must be kept in the document
2. The document should be syntactically valid
3. The author (or previous author) may know more than the tool about
accessibility, or conversely the author may not know anything about
accessibility

We would also like clean markup, but I am not sure that there is a
particular accessibility requirement for this (given that we require
structure to be navigable, bad markup is bad markup generally)

Idea 1 is (in my reading) covered in 2.2 - use applicable accessibility
features. We should add some technique stuff.

Idea 2 belongs in 2.1 - make valid documents. We should have a checkpoint
which says that explicitly.

Idea 3 is a bit more complex.
If the author can write a more accessible markup scheme they should do so,
and include reference to it in the document so a tool can check against
it. At one point we had a proposal to require some published document type
to be used, which would need to be reinstated to make this work.

Where a document received is invalid, we have a difficult problem. The
tool can flag a validity error. If it is known that the document type has
been superseded, it can attempt to validate the document against the newer
syntax. In the case where it cannot find a way to validate the document,
then it can either force validation, by removing whatever "should not be
there", it can produce a document which has no declared type, since it
cannot be validated, it can produce a document which incorrectly claims
conformance, or it can create a document type on the fly to which the
document conforms.

The first of these should never be done without asking the author. That is
a requirement under the checkpoints of 2.5 as they stand. The risk of
forcing compliance is that extra accessibility enhancements will be lost.
I think this only applies to HTML - in XML the rule is that if an element
should not be there then it and its content are ignored.


This allows the reqiurements of 1 and 2 to be satisfied. In the case where
the author knows a lot about designing accessibly, we would expect a tool
to allow them to create their own DTD. In a case where an accessibility
problem could be identified, checkpoints under guideline 2.6 would come
into play. Even in the case of a DTD there are machine-checkable things,
and there is a lot that can be said on how to write a DTD which promotes
accessibility - allowing (or requiring) the inclusion of alternative
content, the seperation of presentation from content and structure, and
supporting device-independence are the basic requirements which can be
expressed at any depth between bullet points and an encyclopedia. This
would be required of such a tool under the current section 2.7

In the case where the author knows nothing about accessibility, checkpoint
2.6.3 and guideline 2.7 come into play.

So I propose that we:

add a checkpoint to 2.1:
Documents should be valid according to a published machine readable (on
the web) syntax. [priority 2]

Techniques: check that the syntax of the document is legal according to
the specified syntax. If there is a known updated version (e.g. HTML,
which is periodically revised) try to validate against the newer version. 
Where a document does not validate, no document type should be claimed for
it.

add a checkpoint:

allow the user to override any structural changes [priotrity 1]
 This includes, but is not limited to changes in the markup and in the
 document type declarations

to replace the checkpoints currently in section 2.5

Charles McCN

Received on Friday, 16 April 1999 17:58:39 UTC