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.

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.