W3C logo WAI

WAI Page Author Working Group

Conference Call Notes for March 11, 1999, 4-5:30 EST

Table of contents

  1. Participants
  2. Action Item Summary
  3. Opening remarks
  4. Item 1: Conformance criteria labels
  5. Item 2: need DTD checkpoint?
  6. Item 3: Make sites usable without text?
  7. Item 4: Nesting and using heading levels
  8. Item 5: Review the priority of image map checkpoints.
  9. Item 6: Image maps in forms.
  10. Item 7: Use of "title"
  11. Item 8: Avoid sending mixed messages
  12. Item 9: Checkpoints 13.3 and 13.4 are incompatible.
  13. Item 10: Link relationships

Participants

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

Action Item Summary

Opening remarks

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.

Item 1: Conformance criteria labels

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.

Item 2: need DTD checkpoint?

Do we need a checkpoint to say that you must conform to an accepted W3C DTD.

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)

Item 3: Make sites usable without text?

Where possible sites should be transparent in meaning without the use of text.

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?
JW: agrees.
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.

Item 4: Nesting and using heading levels

WC: likes the wording suggested by Warner.

Action: Editors change "nest heading" text per Warner's suggestion.

Item 5: Review the priority of image map checkpoints.

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.
GV: agrees.
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"?
GV: sever.
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:

  1. Prefer client-side, use redundant links with server-side [Priority 1]
  2. Until UAs support alt text for client-side, provide redundant links for them. [Priority 2]

Item 6: Image maps in forms.

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 3.
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.

Item 7: Use of "title"

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.
JW: NO.
CMN: we need good examples

Item 8: Avoid sending mixed messages

Don't encourage people to use dumb screen readers with injunctions about word wrapping.

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 data.
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).

Item 9: Checkpoints 13.3 and 13.4 are incompatible.

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.

Item 10: Link relationships

Discuss link relationships more explicitly (e.g., as a checkpoint). Link relationships (rel/rev attribs in HTML) are used already by some UAs to provide navigation tools. This may be discussed in relation to RDF.

IJ: in 15 we discuss something
WC: we should extend 15.2 to include link relationships and add some examples in the techniques.
Action: Ian Jacobs to forward Tim's summarized comment list with resolutions as of today to the list.

Next meetings:

There will be a GL/CG meeting scheduled for Wednesday March 17, 4:15 PM PST ,
Then March 22, and 23 4:00 EST.


Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.