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

Here is an extract of a message which I sent to Wendy on this point
before the issue was raised on the list.

Here is a proposal to solve the problem you raised by e-mail yesterday
(and on the teleconference today) regarding checkpoints 1.3, 3.1 and
techniques. This may or may not apply in other scenarios, and expands
on my suggestions during the teleconference.

In the scenario that you stated, the question was as to the priority
of using certain structural elements in HTML that may not be well
supported by user agents.

Under checkpoint 5.2, the content developer is required to specify a
user agent baseline. If the baseline asserts that full support for
HTML 4.01 (or XHTML 1.0), for example, is assumed, then your problem
doesn't arise because the content is being designed with a level of
technological support in mind that includes all of the structural
elements defined in the HTML 4.01 or XHTML 1.0 specifications.

The problem occurs when the "user agent baseline" does not assume
support for the relevant structural elements. Currently, all that
checkpoint 5.2 requires is that the content continue to be usable when
features above the baseline are turned off or not supported.
Checkpoints 1.3 and 3.1 would continue to demand that the proper
structural elements be used, even if they are "above" the user-agent
baseline; and this would not conflict with checkpoint 5.2 because HTML
user agents are supposed to ignore any elements that they do not
support, so the content would still be perfectly usable in the absence
of support for the elements under discussion.

One solution, which I don't like for reasons to be explained, is to
add a qualification to checkpoints 1.3 and 3.1, or to the guidelines
as a whole, which says, roughly:
The content is not required to make use of features that are not
supported in the user agent baseline.

The problem here is that there are features of clear accessibility
benefit which do not introduce problems under checkpoint 5.2, but may
not be supported in the developer's user agent baseline. If the
developer wasn't required to implement them, users of more recent (and
upcoming) technologies wouldn't gain the benefit of the additional
features, and lots of legacy content would be created that would be
less accessible merely because the developer decided not to design for
the latest (and upcoming) technologies but only for older user agents.
The above proposal also has the consequence that when the user agent
baseline is changed, the list of required features changes with it, so
the entire content would need to be updated to bring it into
conformance (well, that can't be helped, I suppose).

To solve some of these problems , we could differentiate by level:
Level 1: no requirement to make use of features not included in the
user agent baseline

Level 2: Required to use features above the user agent baseline that
are defined in applicable technology specifications and are otherwise
required by the guidelines, including checkpoint 1.3, provided that
the content is still usable when they are turned off or not supported
(i.e., checkpoint 5.2 remains satisfied).

Level 1 would still encourage less accessible, legacy content,
unfortunately. Of course, when the user agent baseline is changed, the
content would then have to be re-evaluated to determine that features
that weren't required under the older user agent baseline, but which
are part of the new baseline, have been implemented where applicable,
according to the success criteria in other parts of the guidelines.

Level 2 would probably have to be defined more precisely but I think
the above outline gives the basis of a proposed solution. The
introduction of "user agent baselines" into the guidelines, and into
our thinking, has consequences that need to be fully developed.

Received on Friday, 12 July 2002 20:49:35 UTC