Issues arising from 31 July draft

Checkpoint 1.1: The term "non-text content" is too broad. Consider,
for example, a document instance conforming to Charles' DTD for
musical notation. This would arguably count as non-text content, but
it shouldn't attract the application of checkpoint 1.1. What is
needed, instead, is software for displaying or typesetting the musical
notation, playing it via a sound system, converting it into braille,
converting it into a spoken rendering, etc., not a "text equivalent"
as defined in checkpoint 1.1.

Suggestion: either change the definition under checkpoint 1.1 to be
exclusive (that is, "non-text content" means exactly the phenomena
mentioned in the definition), or simply say "auditory, graphical and
multimedia presentations" in the text of the checkpoint. Some of the
examples mentioned in the definition (spacers, bullets, graphical
buttons) are very specific to an HTML legacy and also redundant: if
one says "all images" then this necessarily includes the more specific
cases mentioned, which then don't need to be pointed out explicitly in
the definition.

1.2 There is no mention of "multimedia" in the text of the checkpoint,
  yet it is the first term in the subsequent definitions. The term
  "media equivalent" is confusing and not defined anywhere. I would
  rewrite as:
Synchronize auditory and textual equivalents with multimedia
  presentations

Nowhere, though, does it state that auditory descriptions must be
provided; this is left implicit as a result of combining the
checkpoints of earlier drafts and really should be a separate
checkpoint if we want to keep it; or we could modify checkpoint 1.1 to
handle this special case.

In the success criteria, the words "all significant" were criticised
in the teleconference a few weeks ago as being too strong. I would
suggest deleting the "all".

One solution to the checkpoint 1.2 problem would be to insert a note
under checkpoint 1.1 stating that in the case of multimedia
presentations, where the user agent can't render the text equivalent
and synchronize it with the presentation (see checkpoint 1.2), then
the text equivalent must be provided as an audio description.

Checkpoint 1.4: I would generalize to encompass other semantic
distinctions such as emphasis, which are not structural and hence not
encompassed by checkpoint 1.3. I would include natural language
identification as an example. This needs to be developed further.

1.5 The definitions of content, structure and presentation are
  missing. Also, the use of the term "content" here is problematic, as
  has previously been remarked. Perhaps it would be better to say:
  "Separate meaning and structure from presentation". This could also
  have implications for the inclusion of semantically rich metadata in
  appropriate cases.

Guideline 2: the requirement for "navigation mechanisms" (see my
proposal from earlier this week) has disappeared. The requirement to
handle input errors has been introduced as a separate checkpoint,
which is not unreasonable.

Checkpoint 2.2: All of the examples here are visually oriented. We
should try to diversify the examples somewhat to include speech
dialogues, for instance, taking account of all the work that has been
devoted to "voice browsers" in recent years.

Checkpoint 3.1: Same comment as per checkpoint 2.2, but even more so
in this case--the existing text gives the impression that presentation
is inherently visual, which we all know not to be true. Note that
there is an incomplete sentence at the end of the success criteria
(delete the "and").

Checkpoint 3.2: Again no mention of voice characteristics (prosodic
effects etc.), such as those controlled by CSS speech properties.

Checkpoint 3.3: it is ungrammatical: substitute "simply" for "simple"
in the text of the checkpoint. "that you might expect" should be "than
you might expect".

Checkpoint 3.4: The definition of "non-text content" here should be
the same as in checkpoint 1.1. I would suggest generalising and
correcting the definition, then making sure that the same definition
is used in both checkpoints.

Checkpoint 4.4: This still won't work well in the case of XML document
types for which the user agent provides no support by default. Perhaps
it should be restricted to technologies which modify the behaviour
(styling, interaction etc.) which user agents provide by default:

Ensure that content remains usable when technologies that modify
default user agent processing or behaviour are turned off or not
supported. (This wording could be improved but the concept is clear).

Received on Wednesday, 1 August 2001 01:10:52 UTC