- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 14 Sep 1999 18:50:21 -0400 (EDT)
- To: Ian Jacobs <ij@w3.org>
- cc: w3c-wai-au@w3.org
my comments scattered, marked CMN - Ian's marked IJ
On Tue, 14 Sep 1999, Ian Jacobs wrote:
Hello,
I haven't finished reading the AU techniques document
that's part of last call [1] but I wanted to send
these comments anyway. I will reserve most editorial comments
for another review.
1) The document contains very little in the way of
explanatory prose. This means that I think it will
not help a reader unless that reader is a very
informed developer. I think that this draft contains
sufficient information for the Guidelines to become
a Recommendation, but I think the Techniques document
needs to be restructured with more prose, more
explanations, and more rationale.
CMN
I agree that further explanations and rationale would be good. It would also
perhaps provide a way of distinguishing the techniques document from the
guidelines document.
IJ
2) Under checkpoint 1.1:
a) Bullet 1: Provide options for accessibility
information such as equivalent alternatives to be
included whenever an object is added to a document.
I think the case of alternative text should be singled
out. I think "such as" weakens a technique
since the reader has no other place to turn at this point.
There should be concrete examples in place of generalities.
CMN
I would prefer to provide a number of other alternatives, or to include (for
example) the sections from teh sample implementations. In fact I would like
those to be part of the general techniques as well as being available
separately.
IJ
b) Bullets 3 and 4 refer to WCAG 1.0 Guidelines and Techniques.
However, these are covered by checkpoint 1.2, so I suggest
moving these techniques to checkpoint 1.2
c) I think techniques for W3C languages should be listed
clearly, as in:
* Accessibility of HTML
* Accessibility of CSS
* Accessibility of SMIL
etc.
The current wording obscures this.
CMN
I agree
IJ
3) Under checkpoint 1.2
There should be no techniques in this checkpoint other than
references to WCAG 1.0. I feel quite strongly about this
since attempts to include information will necessarily be
incomplete and risk deviating from WCAG 1.0. If the working
group has suggested techniques, those should be sent
to WCAG.
CMN
I am happy with that proposal
IJ
4) Under checkpoint 1.3
a) Template is undefined in the checkpoint text.
b) Please refer to "navigation mechanisms" instead
of "navigation schemata" for consistency with
other WAI Guidelines.
CMN
template is a commonly used word in English - I don't think it needs
definition. Does somebody who does want to propose a definition?
navigation mechanisms also sounds more consistent with the language that
people actually use (grin)
IJ
5) Under checkpoint 1.4
a) The second bullet talks about using "title" for
descriptions of images. This is not recommended by WCAG.
CMN
I think this is a wordng issue. How about changing descriptions to associated
text?
IJ
b) Fifth bullet: WYSIWYG is undefined.
CMN
Actually it is marked up in accordaance with WCAG. That issue should be
referred to the WCAG group.
IJ
6) Under checkpoint 2.1
a) (editorial) Text in the first bullet is repeated.
7) Under checkpoint 2.2
a) I think the checkpoint should read:
"Ensure that generated markup conforms to a published
specification."
CMN
Suits me. Thoughts anyone?
IJ
b) I don't understand the third bullet. It may mean:
"Use schemas to describe transformations from one
markup language to another." This may also be done
with the XSL Transformation language.
CMN
Aaah. Another technique for the checkpoint.
IJ
8) Under checkpoint 2.3
a) I don't understand the example about frames in the
first bullet. It's not clear whether it means "Don't
create a frame document with NOFRAMES" or
"Don't use a DTD for frames without NOFRAMES".
CMN
It means the latter. Should it be reworded, or can someone provide a better
example?
IJ
b) The third bullet should qualify that the statement
applies to the time of publication of the AU Techniques
Document.
CMN
We should list the trigger events which we expect to require changes to this
document - change in status of anything to which we refer is such a trigger.
IJ
9) Under checkpoint 3.1
a) What is the rationale of the second bullet on uppercase letters?
CMN
It is a clue for abreviations - we should make that explicit
IJ
b) Fifth bullet: say "natural language"
CMN Yes
IJ
10) Under checkpoint 3.2
a) In first bullet, say "alternative equivalents" instead of
"alternative information".
b) In the second bullet, say "image" instead of IMG and refer
to a text equivalent instead of alt text.
CMN
I agree
IJ
11) Under checkpoint 3.3
a) The second bullet on clip art long descriptions needs more
explanation.
CMN
I agree.
IJ
b) In third bullet, refer to captions, not "video description files".
CMN
Why? The fourth bullet already does that. We can change the order if there is
value in that...
IJ
c) In fifth bullet, there is reference to pre-written descriptions
that will circulate on the Web. The same was said of shared
style sheets and I don't think in reality that that is the case.
I don't have any data to back up that statement, however.
CMN
TO the extent that style sheets are circulated (the only ones I know of are
the W3C ones that I find referenced from time to time across the web) it does
seem to do all the things suggested (I have worked with these as a private
contractor for just that reason).
IJ
12) Under checkpoint 3.4
a) The first bullet is too detailed and difficult to understand
in its current wording.
CMN
I don't think so, although I would be happy to have a simplification, or a
couple of diagrams indicating what was going on.
IJ
b) In the fourth bullet, there is reference to "alternative
information mechanism" followed by the acronym "ACM". How
do the two relate? Should it be AIM?
CMN
from the first use of the abbreviation:
"...this alternative information mechansim (ACM) have the..."
But I agree that AIM would seem like a more obvious abbreviation. This
happened because we decided to use the term alternative information instead
of alternative content and I missed making the change in the acronym - it is
editorial.
Charles McCN
Received on Tuesday, 14 September 1999 18:50:22 UTC