- From: <pjenkins@us.ibm.com>
- Date: Wed, 1 Dec 1999 12:43:59 -0600
- To: w3c-wai-au@w3.org
I would like to discuss this comment [extent of the tool's
responsibility...] during today's (Wed's) call. I've included background
and details of my original concern.
_________
http://www.w3.org/WAI/AU/ATAG1-PR-issues.html#Extent
Extent of a tool's responsibility in relative priority checkpoints
There is a lot of work for an authoring tool developer to determine the
extent to which they can automatically implement checkpoints in Web Content
Guidelines, which are required by relative priority checkpoints
...
3.] Should we make a matrix of tool requirements
Proposed resolution: This would be useful, but it is not necessary. It will
also vary between types of tools, and as the state of the art changes
__________
I feel this "matrix" is necessary and I do not feel it varies any more than
the existing ATAG checkpoints do for various types of tools. I also feel
the matrix would not change with technology any more than the ATAG
checkpoints need to change with evolving technology.
Background of the issue to help you understand why I feel the way I do:
Phill wrote:
>...
>Although the ERT [1] document is being created as "techniques", it is also
>providing some (it's not finished yet) of the spec level information the
>tool developer needs to know [to be able] to determine if the tool should
support
>that checkpoint. That information needs to be in [ATAG] for it to be
complete.
>The [ATAG] should specify those checkpoints from the [WCAG] that are
>clearly "tool" supportable. The majority of the "techniques" on various
>"how" implementations can and should remain in the ERT [1].
The [ATAG] does not specify what the tool should do vs what the user of the
tool should do when it references creating accessible content that complies
to [WCAG]. The [WCAG] only specifies what the resulting content should
comply with, without specifying whether the resulting content is the
responsibility of the Web author or the responsibility of authoring tool
being used, if any. Quoting from the [ATAG] itself:
Note: Some accessibility problems cannot be detected automatically, and
will require the user to make decisions."
The keyword here is "some". I ask, "which ones cannot be detected
automatically?" By merely saying "some" without someplace listing them,
there is no specificity as to which [WCAG] checkpoints are the
responsibility of the authoring tool, and which are the responsibility of
the user.
Judy wrote:
>2. The type of technical reference material proposed in Phill's matrix
>would not change the content of the guidelines themselves, nor is it of a
>guidelines nature. The guidelines lay out requirements for accessible
>authoring tools that create accessible Web content, while information in
>the proposed matrix would be appropriate as implementation support only.
I feel that my proposal [not the whole ER document] is of a guideline
nature. When the [ATAG] specifies that a tool should check, alert, assist,
etc. it does NOT specify for which of the [WCAG] checkpoints. It only
points to all the [WCAG] checkpoints. It assumes that the tool developer
can or will decide. The [ATAG] must provide guidance here. I agree that
the techniques listed in the ER document and in the [ATAG] techniques
document itself is appropriate as implementation support only.
Judy wrote:
>1. The [ATAG] have an explicit dependency on the [WCAG]; however,
>this dependency is currently version-independent, ...
>Building the matrix of ATAG/WCAG checkpoints which Phill proposes
>into the guidelines would reduce stability of the [ATAG] unnecessarily;
>while building similar information into a supporting Techniques
document...
The issue or question that needs to be resolved is whether or not it is
"necessary" for guidance as to which [WCAG] checkpoints should be
"implementable" by an authoring tool and which are future considerations
for tools and currently the responsibility of the tool's user. My purpose
for raising this issue during proposed recommendation, is that it is in
fact necessary. As a tool developer I am asking for this guidance to be
included in the final [ATAG], otherwise each and any every tool developers
may decide differently, or give up because it's too much work to research
each and every of the 66 checkpoints as it relates to the development of
authoring tools. The [ATAG] does a good job of reminding me to check, or
alert, or assist, etc., but it doesn't tell me WHICH to check, or WHICH to
alert, or WHICH only to document as helpful information.
Judy wrote:
>3. The proposed dependency ... on multiple non-normative documents
>(the matrix, and the "Techniques for Evaluation and Implementation
>of Web Content Accessibility Guidelines" <http://www.w3.org/WAI/ER/IG/ert/
>)
I am not proposing a dependency on the ER document, but I am proposing a
normative section be added to the [ATAG] that specifies which checkpoints
the tools has responsibility for and which is a user/author responsibility.
>Phill has suggested that that document should be completed before
>[ATAG] is considered complete. That would delay the release of the
>ATAG by many months.
I did NOT suggest that the ER document be complete, but that this "new
matrix" section be completed. This "new matrix" section in the [ATAG]
would take considerably less time to complete than the entire ER document.
What Phill originally wrote:
>I'm proposing that a matrix be developed and included in the [ATAG]...
>This matrix needs to be completed by the working group and consensus
>reached...
Judy wrote:
>4. Repeatedly ... , to have less implementation detail in the
>guidelines document and even to remove existing detail rather than to add
>more, so as not to overly constrain developers on their implementation
>approaches.
Adding a guidance matrix on "whether" the tool should implement support or
not, is NOT adding technical constraints as to "how" to implement support
or not. Nor am I proposing to prescribe "which techniques" to implement.
Judy wrote:
>With regard to process, while the timing of these comments from two
>organizations represented in the working group is regrettable, it is
always
>important, and valuable, to receive feedback.
I too regret that I raised this issue during proposed recommendation. This
issue was not uncovered earlier in the process. Although a developer
myself, I represent several developer teams inside IBM. As we worked
through each level of the document we worked through levels of concerns.
This concern was articulated by myself during the final review, as I was
asking myself, "now, do I know for sure how the IBM teams are going to
implement each checkpoint?" As we answered each checkpoint, it became
clear that it was NOT clear which of the [WCAG] checkpoints applied to the
tool itself.
I believe if more tool developer companies had been involved in the working
group this concern may have been uncovered earlier in the process. Now,
however, it is important that each AC representative ask themselves whether
they need to be involved in reaching consensus on which [WCAG] checkpoints
are the responsibility of the authoring tool manufacturer and which are the
responsibility of the user/author.
Regards,
Phill Jenkins, 1-512-838-4517
Accessibility Program Manager, Senior Software Engineer
IBM Special Needs Fax: 1-512-838-2212
11501 Burnet Rd, Austin TX 78758 http://www.ibm.com
Original content of concern from Phill:
-------------------------
The Authoring Tools Accessibility Guidelines [ATAG] needs to return to the
working group because it is not clear what the tool must do and what the
user has responsibility for in producing content that meets the Web Content
Accessibility Guidelines [WCAG].
It is clear as an authoring tool developer I am dependent on the W3C
specification of what a software tool can do. As an authoring tool
developer reviewing the [ATAG], I was instructed to produce content that
complies with the [WCAG]. This is a valid "requirement", but not specific
enough for me as a tool developer to determine what the tool should/can do
and what the author should/can do. Obviously a motivated author for
example, can just use the [WCAG] and code HTML that complies with no help
from a tool. The [ATAG] needs to specify which of the 66 [WCAG]
checkpoints need to be "supported" by the authoring tool.
One of the purposes of the ER Evaluation and Repair Techniques [1] document
is
"... These techniques may be used by those who create web authoring tools
or by anyone interested in creating accessible web documents. "
it goes on to say that ...
"It is clear that only a limited set of the [WCAG]'s checkpoints may be
objectively tested by a software tool. There will still be a dependence on
the user's ability to use common sense to determine conformance to the
guidelines. It is imperative that any tool have features that assist in
reminding, without nagging; in helping, without demeaning; in suggesting,
without demanding. We hope that the techniques in this document,
implemented in software programs, will gently guide authors along the path
to more accessible documents."
For example [WCAG],
"Checkpoint 1.1 - Provide a text equivalent for every non-text element"
has been analyzed by the ER working group and they generated a list of
"techniques" [2] for checking:
Technique 1.1.A - Check images ALT text
Technique 1.1.B - Check images for LONGDESC and descriptive link
Technique 1.1.C - Check input buttons that use images for ALT text
Technique 1.1.D - Check applets ALT text
Technique 1.1.E - Check applets for alternative content
Technique 1.1.F - Check objects for alternative representation
Technique 1.1.G - Check frames for an associated LONGDESC file
Technique 1.1.H - Check AREA elements for ALT text
Technique 1.1.I - Check if audio files have an associated text transcript
Technique 1.1.J - Check SCRIPT element for an associated NOSCRIPT element
Technique 1.1.K - User notification for ASCII art
In the proposed [ATAG] is the checkpoint
"4.1 Check for and alert the author to accessibility problems. [Relative
Priority] Note: Some accessibility problems cannot be detected
automatically, and will require the user to make decisions."
- but the document does not specify which of the 66 [WCAG] checkpoints the
authoring tool, with or without the author's help, should implement. There
is an accompanying techniques document for the [ATAG], but it is not a
definitive spec for each of the 66 [WCAG] checkpoints.
Although the ERT [1] document is being created as "techniques", it is also
providing some (it's not finished yet) of the spec level information the
tool developer needs to know to determine if the tool should support that
checkpoint. That information needs to be in [ATAG] for it to be complete.
The [ATAG] should specify those checkpoints from the [WCAG] that are
clearly "tool" supportable. The majority of the "techniques" on various
"how" implementations can and should remain in the ERT [1].
I'm proposing that a matrix be developed and included in the [ATAG]. The
matrix would lists the [WCAG] checkpoints, and then list the "relative
priority" checkpoints from the [ATAG]. There are 66 [WCAG] checkpoints and
28 total [ATAG] checkpoints, but only 8 are "relative priority or directly
reference the [WCAG]. The matrix would then be 66 by 8 with a Yes, No, or
Not Applicable (NA) to clearly indicate if the authoring tool should
support that checkpoint.
For example, [WCAG]'s
"Checkpoint 4.1 - Clearly identify changes in the natural language of a
document's text and any text equivalents (e.g., captions) ). [Priority 1]
For example, in HTML use the "lang" attribute. In XML, use "xml:lang". "
would be listed against the following [ATAG] relative priority checkpoints
as clearly supportable or not in the authoring tool (i.e., machine
checkable):
WCAG
4.1 ATAG
No 1.3 Ensure that the tool generates markup that conforms to...
No way for the tool to know when the author is changing from French
to English.
Yes 1.4 Ensure that templates provided by the tool conforms to...
Tool developer can manually insure template identifies language
change.
No 3.1 Prompt the author to provide equivalent alternative information...
No way for tool to always know when to prompt.
NA 3.2 Help the author create structured content and separate information
from its presentation.
See 4.2, tool can help when changing char sets, and when using the
LANG attribute
Yes 3.3 Ensure that prepackaged content (such as video captions) conforms
to ...
Tool developer can manually insure language changes.
No 4.1 Check for and alert the author to accessibility problems.
No way for the tool to know when language is changed without author
help.
Yes 4.2 Assist authors in correcting accessibility problems.
Tool would include help information covering language changes.
No 5.2 Ensure that [WCAG] Priority 1 accessible authoring practices are
among the most obvious and easily initiated by the author.
This matrix needs to be completed by the working group and consensus
reached on the specification for the tool developer. This matrix could be
a separate section that can be updated if and when the [WCAG] is updated.
[1] http://www.w3.org/WAI/ER/IG/ert/
[2] http://www.w3.org/WAI/ER/IG/ert/#Checkpoint1.1
[ATAG] http://www.w3.org/TR/WAI-AUTOOLS/
[WCAG] http://www.w3.org/TR/WAI-WEBCONTENT/
Regards,
Phill Jenkins, 1-512-838-4517
Accessibility Program Manager, Senior Software Engineer
IBM Special Needs Fax: 1-512-838-2212
11501 Burnet Rd, Austin TX 78758 http://www.ibm.com/sns
Received on Wednesday, 1 December 1999 13:47:58 UTC