Conference Call Notes for March 11, 1999, 4-5:30 EST
CL: Chuck Letourneau (note taker)
CMN: Charles McCathie-Nevile
AG: Al Gilman
DD: Daniel Dardailler
WC: Wendy Chisholm
JW: Jason White
GV: Gregg Vanderheiden
IJ: Ian Jacobs
GV: We are operating under a new set of rules. A written disposition is required. Tim Berners Lee will review all our responses to all the comments.
Note: Items 1-6 are from the issues message on the list. 7-10 were raised in a separate commuication with Tim Berners-Lee.
P1, P12, P123, currently. Various suggestions to change those. What are we
going to do?
CMN: conformance ratings are opaque, arbitrary, so lets not worry about it.
GV: thought that the P series were not opaque and could be read logically. They cannot be misunderstood.
AG: dissents. Should be mnemonic. Says AAA is better than AA, and all are better than the P series. Daniel agrees.
GV: how will screen readers read it?
AG, JW: use ACRONYM, ABBR and screen readers can set library pronunciation.
DD: main audience is not persons with disabilities.
GV: disagrees with that sentiment.
DD: mentioned Chuck Hitchcock of Bobby who doesn't like P123. Likes the AAA type.
AG: thinks that AAA tells you something even if you haven't read the document. The P rating assumes you must have read the document.
IJ: doesn't actually care much, but sees some advantages to the AAA system. Not against.
CL: agrees with Ian's sentiment.
JW: not keen on A's but not going to argue..
CMN: bare (minimum) conformance, standard conformance, super (exceptional) conformance
GV: calls the question: change, table, or what? How would it read?
IJ: level A, level AA, level AAA (for compliance with 1, 1 and 2, and 1, 2 and 3.
JW: against it because of pronunciation and doesn't correspond to the document.
GV: hears more support for A's than P's.
WC: leaning more to A's.
GV: moves to go to A, AA, AAA levels of conformance.
CL: what about alt text=A, Double-A, Triple-A?
DD: with icons for A, AA, AAA
Resolved: Editors will use A/Double-A/Triple-A conformance levels in next release.
JW: thinks it used to be in the guidelines, but has disappeared.
IJ: HTML 4 requires the doctype declaration.
JW: html of any version is an SGML dtd and therefore requires a doctype.
IJ: might be referring to another organization's dtd. When schemas are around, you wont need it.
WC: thinks it should be up to the editors to come up with the wording of a new checkpoint. But what would the priority.
AG: sees it as clarifying the checkpoint that was read originally.
WC: but this checkpoint only corresponds to W3C.
GV: then we do need a separate checkpoint. It doesn't make a page inaccessible, thus not P1
JW: depends on the degree of non-conformance
IJ: then there are two issues: first you must specify the dtd to which you conform, and you must conform to a dtd.
WC: sees it as a P2 or P3, JW thinks it depends.
GV: let's decide.
JW: thinks it should be P2
IJ: Proposed wording: "Author documents that validate to published formal grammars (e.g., document type definition, and schema) and identify those grammars.
Resolved: IJ will send DTD checkpoint wording to list (Priority 2)
GV: the question is how many people who can't read would be able to
understand a page if you took the words off? Almost none.
WC: then we have covered illiteracy adequately?
GV: thinks we should say that this suggestion does not practically address the problem.
DD: what about speech synthesizers for persons who are illiterate?
GV: illiteracy is not considered a disability. Not many people without disabilities have screen readers.
Action: GV will work with Wendy to word the response to groups decision on handling illiteracty and non-readers in the document.
WC: likes the wording suggested by Warner.
Action: Editors change "nest heading" text per Warner's suggestion.
1.4 and 1.5 - review the priority, especially for client-side image maps
WC: other people had similar issues to Gregg Lowney's comments. Should not
be priority 1. Agrees with P1 for server side, but not so high for Client side
because multiple links will appear soon.
WC: if this really should be dealt with on the UA side of things, maybe we don't need such a high priority.
IJ: Tim Berners Lee says it must be very clear in the guidelines to distinguish what is UA, AU, or other responsibility is critical to describe.
GV: we took great care to move temporary items from most other places. Should we move this one?
WC: the other ones were very kludgy. This one does fit well with Image Maps.
DD: is there a checkpoint that says use client side rather than server side image maps?
WC: we used to have that as a checkpoint. Now we have just made it more general. Something needs to be added back in in "device independence" to use client side.
Proposal: add a checkpoint.
AG: is it a simple or severe usability problem to identify the alt-text in a "view-source"?
JW: let it be P2 until UA's support alt-text in client side image maps.
DD: Make a checkpoint: should use client side image map or server side with redundant links (P1)
JW:: Make a checkpoint: Use redundant P2 on client side image maps until such time as major browsers support alt in image map
DD: do we agree to move redundant links into the legacy issue?
AG: we want to assert the legacy issue with an "Until" clause.
DD: that is fine.
IJ: how about: something about infinite or complex maps
JW: things that can't be defined by the standard shapes. Proposed: use client side images with alt text unless the regions cannot be defined with the geometrical shapes provided with client side image maps
Resolved: Editors will modify the checkpoints related to image maps to convey the following ideas:
4.1 and 4.2 - does the priority of 4.2 decrease when 4.1 is done well?
Gregg Lowney A.1.5 As with A.1.4, it should be ok to use client side image
maps as long as there is ALT on the AREAs so we should reduce priority to
IJ: What are the attributes on input? Both ISMAP and USEMAP can be used in the revised HTML 4.0 spec.
GV: thinks we don't have a problems. It can be a priority 3 because.
Action: DD: Look into how image maps can be used in forms.
Resolution: postpone discussion until DD has responses.
Tim says title is intended to be used as an advisory note indicating the
nature of a link and not be used to describe the nature of content.
JW: agrees with Tim
IJ: question is, what mechanism do we use to provide brief descriptions.
JW: in OBJECT, use the content.
GV: then there only a functional description or a long description. And what does that do to IE.
JW: takes great exception to taking into account a bug in a particular browser.
IJ: but pop up tool tips are not disallowed.
GV: does anybody have a suggested change to the guideline that addresses Tim's comment?
Resolved: don't say to use title to provide alternative text for images in OBJECT.
Next: in what way should we say for HTML 4 to provide brief descriptions.
GV, JW: we don't need anything else. If a brief description is not needed , then don't do it. IF it is necessary, then it will appear in the alt-text as the function of the image, otherwise it will be in the longdesc.
IJ: we must be careful about using imprecise language. We should move ...
Resolution: Don't say to use "title" for alternative text for OBJECT.
Action: Editors will clarify the use of "title," particularly for OBJECT.
GV: do we need to add a functionality for short descriptions when none is
provided in HTML 4.
CMN: we need good examples
IJ: this is to encourage correct use of mark up. People shouldn't
misunderstand that all tables are inaccessible. You should still use tables for
WC: guideline checkpoint in 12 covers that.
DD: it is an interim solution.
WC: from this checkpoint we can make a note pointing to the proper checkpoints about using tables.
IC: partly an editorial task to go through document to make sure we are promoting the right thing globally and to fix promotion of wrong things.
GV: but if 12.5 is there, then it looks like we are saying that tables are not accessible.
No Resolution: come back to this or review the language.
Action: Editors review document to ensure we are "promoting the right thing" (i.e., avoid promoting kludges over the right way of doing something. ensure don't send mixed messages).
IJ: subsume 13.3 into 13.4: should say, use content negotiation, and use
specific author side type information when necessary.
WC: what about making the guideline more general and put examples in the technique document.
IJ: Tim wants to come out strongly for content negotiation.
IJ: things like auto refresh are in techniques document so Wendy's comment is probably appropriate.
WC: can the editors take this one and work on it?
IJ: lets get a clear idea: should there be a checkpoint that addresses content negotiation
DD: and the "types" of the content
IJ: doesn't think so.
IJ: Ensure that users can select from among resources that differ by language or format.
DD: would want to "know" what the resources available are.
IJ: need to look at the spec to find some better language.
Priority 3, and other stuff goes into technique document.
Proposed: A single checkpoint about ensuring that users can select (or not select) from among resources that differ by language, content-type, (what else does HTTP provide?) Put content negotiation or "type" in techniques doc. Or "that can be selected by content negotation". Priority 3.
Action: Editors will take discussion of proposal for checkpoints 13.3 and 13.4 to the list.
There will be a GL/CG meeting scheduled for Wednesday March 17, 4:15 PM PST
Then March 22, and 23 4:00 EST.