[techs] Technologies that don't support conformance (Re: Issues raised from Techniques teleconference)

 > 
 > 2. Technologies that don't conform to the guidelines
 > 
 > For some technologies, it might not be possible to meet all WCAG checkpoints
 > in that technology. There are two possible reasons for this: a) the
 > technology is intended to be used alongside another technology that does
 > meet WCAG, e.g., CSS, b) the technology is not fully WCAG-conformant.
 > 
 > In the first case, there may be a "path" by which the technology essentially
 > does meet the guidelines. When examining CSS used with HTML, if any of the
 > Core, HTML, or CSS Techniques documents provide a Technique to implement a
 > given Checkpoint, the CSS can be said to conform and the omission of
 > relevant Techniques from the CSS Techniques document would not pose a
 > problem - the Checkpoint would be deemed "not applicable".
 > 
 > In the case that there is no possible way to implement a Checkpoint in a
 > given technology (e.g., a plugin), there would be no "path". The omission of
 > relevant Techniques has a different meaning and would be a problem as it
 > would not be possible to follow the Techniques document and arrive at fully
 > WCAG-compliant content - the technology is "non-conformant".
 > 
 > The question is, how do we want to address this issue? One approach would be
 > to provide Techniques for Checkpoints that can be met in the technology, and
 > indicate that missing techniques were not omitted or not applicable, but
 > could not be created. This would have the advantage of providing guidance
 > for users to create documents or implementations that are "as WCAG
 > conformant as possible", which is better than nothing, and supports the idea
 > that some technologies are taking steps towards complete accessibility
 > though they are not there yet. The second approach would be simply to say
 > that the technology is non-conformant, and provide, essentially, a single
 > Core Technique that says "provide equivalent alternatives if this technology
 > is used". This approach supports the creation of fully WCAG-compliant
 > content but at the cost of locking out technologies.
 > 
 > Note that even though we do not see this problem arising immediately because
 > WAI will only provide Techniques for vendor-neutral technologies, we desire
 > to address this issue in the requirements. This is because we hope that
 > other organizations will adopt the format we have created to provide
 > Techniques for some vendor-specific technologies, and because other W3C
 > groups have expressed an interest in adopting the Techniques format we are
 > defining, and the issue may arise with the guidelines used by those groups.

I suggest that in the case under discussion we should establish a rule
that no techniques may be published by the WAI for technologies in
which, even if combined with  other relevant technologies, can't be
used to attain conformance. We can't set rules for other
organisations; all we can do is ask them not to publish techniques
documents using our format that are misleading as to whether their
technologies support WCAG conformance or not.

My concern is that if a content developer finds a techniques document
corresponding to a given technology, the assumption will be made that
it is possible to write accessible content using that technology, even
if the only way to create WCAG-conformant content is to provide a
complete alternative version in some other format. Thus to avoid the
confusion that would otherwise result I suggest we make it clear that
we strongly discourage the publication of such techniques documents
until such time as the technology has been improved to the point of
supporting WCAG conformance, and that if such techniques documents
(for technologies that don't presently offer the necessary support)
are published, they should carry clear and prominent notices stating
that pending future developments, it is not possible to write
WCAG-conformant content using this technology, and advising that
alternative versions of the content in other formats be provided.

To summarize, I am suggesting that (1) we don't publish any such
documents, and (2) that we discourage others from doing so, but if
they are going to do it they should provide very clear statements to
developers to the effect that their technology doesn't support the
creation of WCAG-conformant content.

As I said, though, we don't have any control over what third parties
might decide to publish. However, it would be very misleading indeed
to publish a document that purports to be WCAG 2.0 techniques, but for
a technology in which it isn't possible to create WCAG-conformant
content.

Received on Saturday, 11 January 2003 00:35:42 UTC