Chair: Ian Jacobs
Date: Wednesday, 1 December 1999
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C
Tobin Bridge (+1) 617-252-7000
Regrets
Refer to resolutions and new action items below.
Not done.
Done. As a result of the discussion, his issues 7-10 are dropped.
Pending.
Done.
No objections here to new meeting time starting 6 January: Thursdays 1-2:30pm ET
Pending
DB: Tim Lacy has one issue related to virtual machine. DB will have the message forwarded. Otherwise not problem.
Action DB: Ask IE Team about publication of review of IE 5 and Pri 1 checkpoints.
DB: Contacted, no news back.
Done. (URI??)
Done. Refer to GR comments on pseudo class for lang
Done. Refer to Marja comments on this
IJ: Two reviewers felt that checkpoints should be organized according to developer tasks.
DP: I saw a comment from Lake that developers need to have information rapidly and according to needs of developer. Put the meat up front. Tim Lacy had made the same comment at the face-to-face.
MQ: You have to know what the meat is. People's ideas differ, so you're back to square one.
IJ: What about reorganization based on categories of developers (e.g., UI v. content).
DP: If we reorganize, I like UI v. content.
No resolution.
Checkpoint for text magnification/shrinking with maintenance of relative scaling?
HB: I prefer NN's solution to IE's.
DP: Don't we address this in the configuration checkpoint.
DP: What happens today in NN and IE?
HB: Netscape does scaling.
MQ: IE 5 gives you a list box with five choices.
DB: There's a button in the latest IE.
DP: NN doesn't tell you when the end of decrease occurs. It doesn't cycle around.
MK: You also want to be able to go to the default.
MK, MQ: This sounds like a technique.
JA: You can use the mouse + wheel to scroll sizes in IE 5.
HB: There's another observation: we're magnifying without refolding. The IE approach scales and reformats. Scroll bars appear if necessary.
MQ: Do we want to "standardize" this?
IJ: I would say at most checkpoint Pri 3.
DP: For screen readers, it is useful to be able to shrink text size.
MQ: What if a person has large print already?
EH: When you normally increase the font size, you change text wrapping.
HB: A screen magnifier doesn't wrap.
EH: That's what I"m thinking about.
No conclusion. Take to the list.
IJ: Issues 7-10 dropped based on Ian/EH telephone call.
EH#11: Closed captions to captions.
IJ: comments still coming in on that one.
Re: "Braille" or "braille".
IJ: We resolved last week "Braille".
IJ: Haptic - comments still coming in.
EH#16: "continuous equivalent track" v. "synchronized equivalent"
MK: Depends on what you want to emphasize - time-dependency or synchronized
EH: I even have concerns about "synchronized equivalents". I think it has some of the same problems or ambiguities. I don't think it's necessary since we already talk about the synchronizations that we want in the definition of caption, auditory description, and transcripts for audio clips. I think it suffices to name what we want rather than using an additional term.
IJ: I think the abstraction is useful conceptually.
MK: I think what we were emphasizing in the SMIL Access Note was their time-dependency. You can synchronize discrete equivalents as well.
EH: What does synchronization mean in the context of matching discrete elements with its auditory equivalent? If you have a text box with a collated text transcript and a movie besides it, is that synchronization?
MK: You can synchronize the beginning.
EH: In the context of the present document, I don't see any reason to use the term "synchronized alternative" since we can identify what we're talking about.
EH: WCAG 1.3 can be broken down into two simpler checkpoints with explicit reference to the elements (captions, auditory descriptions, etc) we're talking about.
EH: In short: "synchronize" is part of the definition of the alternative, so not necessary to repeat it.
MK: I like the idea of explicitly saying what is needed.
EH: I think there needs to be some flexibility in time coordination between components that's nto implied in the current definition of "synchronization".
MK: We need to explore what "synchronization" means in different situations.
Action MK: Write some comments on synchronization to the list.
IJ: Examination of checkpoint 2.5. Only one checkpoint where "continuous eq" occurs.
Action EH: Propose new wording for 2.5
EH Issue #18
Proposed new checkpoint to meet WCAG 1.3 demands for auditory descriptions.
Refer to Marja comments on this proposal.
MK: There is a problem - the text equivalent might not contain the time codes. These are needed so that the text equvalent is synchronized correctly with other audio. The author needs to put in the time codes. This is a lacuna of the Web Content 1.3.
EH: I agree.
GR: The requirement would be applicable for UAs that support speech.
IJ: Need to amend "native" to include features of the operating system.
Resolved: Amend "native" definition to include features provided by the operating system.
DB: We're not requiring that UAs be able to recognize time codes.
MK: If we want equivalent of time codes, we are. It would also be useful to be able to read the collated text transcript on its own.
EH: The requirement of full synchronization with full transcript is not a Pri 1 requirement.
IJ: I think there are so many prerequisites towards getting this done, that the requirement is too watered-down.
MQ: This sounds like something people choose to implement, but it doesn't sound like it's possible today.
MK: One thing that is possible is that, if you have text-to-speech, you should be able to use it with the browser.
DB: My problem here is that we're requiring something of all user agents.
EH: One suggestion was for a provision more or less stating "When W3C produces a spec describing how to synchronize, then follow that spec." Something has to be in UAGL that points to this WCAG requirement.
IJ: This is covered by Guideline 6.
IJ: I don't think 1.3 necessarily maps to a UAGL requirement. I think this is similar to "Implement tables."
GR: I think we need to talk to PF. And get a more concrete proposal. This may be an issue that can't be resolved before PR.
IJ: Why is this different than "implement lists"?
EH: One difference is that there's an explicit requirement in WCAG. I think clarification is required in the WCAG WG (what are we talking about with "synchornized alternatives"). Then we need to follow through with other W3C Guidelines.
Action EH: Refine proposal on the list.
MQ: Get Windows media people to comment on this.