Re: Trying to better explain concern about mapping technology-specifics to success criteria

As a practical point, T.V. Raman's Emacspeak software applies aural
CSS, allowing it to give a distinctive spoken rendering of each type
of HTML element; it can also invoke XSLT style sheets to give, for
example, an outline of the document or to render tables more
intelligibly.

This is just one example of what can be and has been achieved in
actual implementation. Of course, braille translation software, as I
pointed out in an earlier message, also relies heavily on proper
document structure in order to generate appropriate formatting. The
advantage of SGML, XML, therefore HTML/XHTML, Docbook, the TEI DTD,
Daisy/Niso, SVG etc., is the support they provide for distinguishing
structure from presentation, allowing content to be reused and
transformed in ways that the author may not have had in mind
originally. The problem with designing content only to satisfy the
features available in popular assistive technologies is that it
assumes some peoples' assistive technologies are more important than
others, limits the ability of current and future technologies to take
full advantage of the logical structure, fails to gain the benefits of
separating style from structure (including more powerful styling
options with CSS, XSLT etc.); and adds to the legacy of poorly
structured content that will be with us for years to come.

For purposes of checkpoint 1.3 and setting priority levels, the issue
is not what assistive technologies support or do not support, but
rather which semantic distinctions are most important. This is
basically the approach currently taken in 1.3, success criterion 2, as
well as in checkpoint 3.1. I think it would be worthwhile to review
these success criteria and decide which should fall under each
checkpoint, but I don't have time to think it through just at the
moment.

What the first success criterion in 1.3 means, in effect, is that if
you are using style to convey a certain structural distinction
(layout, fonts, or in a speech application, voice characteristics
etc.), then you must ensure that the proper structural markup is
included so that all the distinctions you have taken the trouble to
emphasize using style characteristics are also expressed abstractly in
the structure. In other words the first success criterion of 1.3 ties
the author's decisions regarding structural markup/data model to their
decisions regarding presentation: whatever structure is distinctive in
the presentation should also be distinctive in the more abstract,
structural markup.

The second success criterion is supposed to catch those cases in which
there is no intended presentation (the author hasn't bothered about
presentation; perhaps the content is in a format which isn't intended
to be presented directly to the user, but will be presented after
other transformations have been applied to it; or perhaps not all of
the distinctions important to accessibility are made in whatever
presentation is associated with the content, though the latter
possibility should be ruled out by checkpoint 3.1). One way of
thinking of it is as follows:

Whatever structure is clearly evident from presentation must be
explicitly given in abstract, structural markup or a data model.

Checkpoint 3.1 requires that the structure be provided in the first
place, that is, the author must impose structure upon the content that
is created, and must, moreover, do it in such a way as to enhance
navigation and comprehension.

As I said, I think these success criteria could benefit from some
work, but I don't have time for it in the near future; but if anyone
wants to examine the issues further they are most welcome to put
forward a proposal.

Received on Monday, 15 July 2002 02:04:25 UTC