W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2003

Issues raised from Techniques teleconference

From: Michael Cooper <michaelc@watchfire.com>
Date: Fri, 10 Jan 2003 18:20:38 -0500
Message-ID: <D9ABD8212AFB094C855045AD80FB40DD0107DD3A@1wfmail.watchfire.com>
To: "WAI GL (E-mail)" <w3c-wai-gl@w3.org>

During the Techniques teleconference on Wednesday, some issues came up that
we felt needed the attention of the entire group. These issues are
testability, Techniques for technologies that don't meet WCAG, and variable
user agent support for Techniques.

1. Testability

One proposed requirement is that Techniques state whether they are testable;
that has been further refined to be that they should state whether they are
a) machine testable, b) not machine testable but human testable, or c) not
testable. "Machine testable" means that a machine can validate conformance
to the Technique without human input. We include the possibility of "not
testable" Techniques for those that apply to Additional Ideas in a WCAG
Checkpoint and are not required to be testable.

In discussion we identified a couple issues with this. First, the line
between machine testable and not is fuzzy. As evaluation tools improve a
Technique that was not machine testable may become so; therefore it may not
be desirable to hard-code the testability nature. Second, we could not agree
that Techniques could ever be truly untestable; if that were the case, there
would be no measurable benefit if a document includes features guided by
Additional Ideas. Although we did not propose removing the requirement to
provide information on testability, we think that testability is unclear and
needs further discussion.

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.

3. User agent compatibility

There is a requirement that each Technique state the user agents in which it
works. This is useful information, but complex and subject to frequent
change. For instance, for some Techniques there may be no current UA
support. For others UA support may be partial or variable (e.g., accesskey
is supported by some browsers now but it locks out access to menu items that
use the same access key - is that "full support"?). There may be other
Technique combinations in which a given technique is preferred when target
UAs support it (e.g., tabindex to move navigation to the end of the tab
cycle) but an alternate Technique may otherwise be needed (e.g., a skip
navigation link).

Furthermore, User Agent support is likely to change fast, possibly faster
than we are likely to update the Techniques documents. There is therefore a
desire to externalize the user agent support information, and point to it
from the Techniques document. If we do this, we will need to set up a
repository of that information. We will additionally need to figure out how
Techniques documents can point to this information, when the information is
newer than the Techniques doc. One possibility would be that the repository
actively point into the Techniques rather than the other way around, but if
so how does this affect our definition of this requirement? 

Michael Cooper
Accessibility Project Manager
Watchfire
1 Hines Rd
Kanata, ON  K2K 3C7
Canada
+1 613 599 3888 x4019
http://bobby.watchfire.com/
Received on Friday, 10 January 2003 18:20:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:21 GMT