Re: principles

I agree in large measure with William's comments. Though it would be
possible, in principle (if the pun may be thus excused) to subsume all of
the requirements under a single overarching maxim, for purposes of
grouping the more concrete requirements and elucidating the nature of what
constitutes accessible design this would be highly unhelpful.

We need to arrive at a balance between generality and specificity in
formulating the highest-level requirements; these serve as categories
within which to organise the more concrete desiderata. This reasoning
justifies writing principles 1 and 2 as separate requirements.

The inclusion of "browsing" in principle 4 has its origins in T.V. Raman's
doctoral thesis, where it is used in contradistinction to "navigation".
Essentially, there is a difference between navigating (crudely expressed,
finding one's way to a particular point in a document, to stress the
spatial metaphor) and browsing the document's contents. In the latter
activity, one is reaing the document non-sequentially, for instance by
concentrating on particular features or structural components. For
example, in perusing a journal article, one might at first read only the
headings, look to the footnotes to determine which references are being
cited, and then direct one's attention to particular sections of interest.
This is different from merely navigating the document--that is to say,
searching for particular material within it, for instance via the table of
contents or other navigational apparatus.

I think it is important to recognize that structural markup serves as a
basis for both browsing and navigational activities and that although both
aspects overlap, they are nevertheless distinct.

Obviously, what this amounts to in specific terms will be elaborated in
the more concrete requirements (checkpoints etc.) and also in whatever
explanatory text accompanies the guideline.

Regarding Principle 5, won't it always be true (so long as there is
technological change) that older standards, data formats and applications
will have to coexist with the new, and hence that some degree of backward
compatibility will always be needed, especially where there is a plurality
of software solutions available and the needs of diverse communities of
users, with various hardware devices and software requirements, are
involved? In brief, it seems unrealistic to conclude that such issues are
likely to vanish, however much we might wish that they would do so.

Disclaimer: the foregoing comments, as usual, are made in my personal
capacity only.

Received on Wednesday, 16 August 2000 22:45:18 UTC