Re: Modularization proposals

** functional concept **

The virtue of a database approach to maintaining our knowledge of barriers and
how to avoid them is that the information pertinent to a specific design
decision can be isolated by algorithm and rich backups provided to the user of
the knowledge.

The killer Ap is a site designer's associate which will take a mockup or a
higher-level description of a feature that the designer wants to implement,
and
report:

a) a list of thumbnails of the potential access issues with such a construct
(with links to details) and

b) a similar shortlist of the top three to five feature-combinations (solution
options) in combined score of a) popularity on the web and b) usability
ratings
from testing with users with disabilities.  Each solution option is
represented
in a UML-like design overview and links to live sites illustrating the
component techniques applied in this synthesis.

There is a genuine tension between the idea that "we have a charter to produce
guidelines" and the idea that "we have a mission to clean up the accessibility
of the Web."

The most useful modules are not only separated in one axis, such as functional
impairment involved in critical scenarios, but in all dimensions that cause
changes in the recorded knowledge.  In fact once operating in a database
environment, there is a strong motivation not to aggregate blocks but make the
least level record the unit of update.  The various clauses form a tuple space
with multiple keys dealing with disability (or situation-dependent user
ability
profile), function (to be performed in the context of the Web Ap), and
technology.

An example of a module with a _raison d'etre_ is tracking the state of
implementation; developing the information needed to decide when 'until user
agent' clauses have been met.  One really wants to keep this information at
arm's length because it is continually changing while other productions are
not.

So in the Web Accessibility Knowledge Base there are two main views: an
application view (web-designer's view) and a change-control view (which
requires making sure that a technique has been evaluated in a suitably wide
distribution of usage situations, worries about longitudinal compatibility
across changes, etc.).  

But there are other views.  To do a format review, PF would annotate the
format
proposal with functions performed, using the function taxonomy used in the
knowledge base.  This would then give us comparable access solutions per
feature for the features in the new format.  We would be able to see where
they
should have re-used a feature because an accessible implementation of the same
function is available in a module compatible with integration in their
application.  Actually, PF would just double-check this analysis as performed
by the format designers.

Putting ourselves in the box of change control policies inherited from paper
documents has added at least a year to the release date of the User Agent
guidelines and has materially reduced their effectiveness because implementers
have so much difficulty mapping the technology-independent language to what
they actually do.  [Do you hear echoes of the web designer reaction to WCAG
1?].

We should be moving in the direction of an application designer's associate
running off a knowledge base with all deliberate speed or we shall be falling
farther and farther behind the growing edge of the Web.  It's just
accelerating, even in the downturn.  To find stable things to say we have
to be
working in a medium that copes with perpetual change.  If the tools don't
manage that for us, we are caught on a treadmill and don't get to do real
work.

** incremental opportunities **

Starting from here, it looks like maintaining document prose in XML or XHTML
and relying on class marks a lot for the properties that index the contents. 
Either it is done with a relational design and keys in classes or it is
done in
XML with X-Link, as the X-Link compatible version of XHTML is still being
worked on.  Or can we fudge it with a retrofit module that upgrades XHTML 1.1
with just X-Link?  Better to do a GuidelinesML from scratch, that is to say
from TREX, RELAX-NG or XSD.  We may yet wind up with application-defined
classes in XHTML lookalike syntax, however.

To design a to_be architecture for the knowledge base driven version, one
starts with scenarios for application by site-and-Ap designers and for
knowledge base update applying real-user testing results.

Getting the model from the scenarios and the schemas from the model is an area
where we may need to call in fresh troops with OMG experience.  Getting a
syntax out of a marriage of the design-based schemas and XHTML should be
something we can handle within W3C.

If we can pull this off it will create a spec-for-spec methodology that solves
a lot of problems in the wider W3C.  But don't sell it as that until it is
working.  We have the excuse that we have to track what the fickle web design
community is fadding about now.

HTML WG really wants this sort of input; but we have to organize our
infrastructure for continuous but rule (distribution of evaluations)
conforming
update to provide them with a feed that is current and of a high quality.

Al


At 09:31 PM 2001-08-20 , Jason White wrote:
>Without committing myself to any of these, I would like to summarize
>the three aspects of "modularity" or "sectioning" which have been
>considered in working group discussions, not only in recent threads
>but also in earlier deliberations.
>
>1. Modularity of the conformance scheme: it has sometimes been argued
>   that (to use Charles McCathieNevile's helpful terminology)
>   device-independence, interaction and navigation, and comprehension,
>   respectively, should be treated as belonging to separate dimensions
>   of conformance. It would thus be possible to make different
>   conformance assertions with respect to each dimension. A precise
>   proposal of this kind has not so far been formulated, but there are
>   two obvious possibilities:
>
>a. A two-way split, with device/modality-independence on the one side,
>and interaction/navigation/comprehension on the other.
>
>b. A three-way split, with device/modality-independence,
>comprehension, and interaction/navigation, occupying separate
>dimensions.
>
>Such an approach need only affect the definition of conformance, though
>it may of course be combined with proposals 2 and/or 3, below.
>
>2. Organisation of the document: it has been suggested that the
>   ordering and normative content of the guidelines should draw clear
>   distinctions between the requirements related to
>   modality/device-independence, interaction/navigation, and
>   comprehension, respectively. Again, as in proposal 1, it would be
>   possible to envisage a bipartite or a tripartite division of the
>   material. Nevertheless, even if the guidelines were organised so as
>   to provide a clear separation between modality/device-independence,
>   interaction/navigation and comprehension, this would not
>   necessarily preclude a unified conformance scheme. Consequently, it
>   would be feasible to implement proposal 2 with or without proposal
>   1.
>
>3. Division into separate documents: This is an extension of proposal
>   2, whereby each element would be treated in its own, individual
>   document. If each such document were a separate Recommendation,
>   then presumably it would be necessary to implement proposal 1 as
>   well, since each Recommendation would be required to provide its
>   own conformance scheme. Of course, it would be possible to regard
>   all of the documents as a single Recommendation, with the
>   separation being largely for the sake of convenience.
>
>The role of the conformance definition in the guidelines has two
>aspects:
>
>1. Its primary purpose is to prescribe the information that must be
>   provided by any content developer who wishes to make a claim
>   regarding implementation of the guidelines. Thus, those who assert
>   that they have implemented WCAG must specify the version of the
>   document to which their claim refers, identify the web content to
>   which it relates, and indicate which checkpoints have been
>   satisfied.
>
>2. The WCAG 1.0 conformance scheme also imposes a hierarchical
>   structure upon conformance claims, based on checkpoint priorities,
>   resulting in the "a", "double-a" and "tripple-a" levels. This
>   aspect of the conformance system has been criticised on the basis
>   that it discourages implementation of lower-priority checkpoints by
>   developers who, for whatever reason, decide not to implement all of
>   the checkpoints of higher priority. One solution which has been
>   offered is to permit checkpoint-by-checkpoint claims of
>   conformance, in which the developer enumerates the checkpoints
>   which have been satisfied, for instance in RDF metadata. One could
>   also say, for example, "Level double-a plus checkpoints x.x, y.y,
>   ...".
>
>Proposal 1, above, could perhaps be implemented by allowing two (or
>three, depending on the nature of the split) types of conformance
>assertion:
>
>1. Device/modality-independence, at levels A, AA and AAA, defined
>   according to checkpoint priorities as in WCAG 1.0.
>
>2. Comprehension, at levels A, AA and AAA (or perhaps with a different
>   measure of comprehensibility/required cognitive abilities of
>   audience).
>
>3. Interaction/navigation, at levels A, AA and AAA.
>
>in addition to
>
>4. Assertions regarding implementation of individual checkpoints.
>
>The arguments which have been (and will probably continue to be)
>raised against such a scheme is that it is complicated, and that it
>fails to recognise the linkages between device/modality-independence,
>on one hand, and interaction/navigation/comprehension on the other.
>Advocates of such a conformance definition, however, will probably
>argue that conformance determinations will increasingly be made with
>the aid of evaluation tools, thus reducing the import of the
>complexity argument. Also, it will probably be contended by some that
>a compartmentalisation of the guidelines which distinguishes
>device/modality-independence from interaction/navigation/comprehension
>is not only feasible but also advantageous.
>
>I hope this summary helps to clarify the issues and to inform further
>discussion of these difficult and contentious topics.
>

Received on Tuesday, 21 August 2001 12:34:20 UTC