See also: IRC log
<janina> scribe: janina
jf: Really one agendum, to see whether we can get to a single proposal on transcript
silvia: We're optimizing to be
able to display in the video controls -- so the video player
can expose transcript
... Not found a player that does that
... Would be happy to know about examples or to hear that
that's what someone is planning to do
jf: When the nonvisual player
gets to the video element they get a set of available media to
run. If we put transcript outside that list that's a
problem
... If there's another way, good. But we can't simply rely on a
stand-alone button.
... We already expect authors will try to put content
exclusively for screen readers into the page--and we need to
provide a way to do that that will be straight forward
<Zakim> janina, you wanted to ask where captions, subtitles, and video descriptions will be made available?
<JF> ack (an
janina: important for a11y to present all alternative options in a set of options
<JF> ack answer)
silvia: assuming we want
transcripts and also for sighted users ...
... Trying to find example where transcript is displayed as
part of player or on page somehow
... Usually displayed below video player -- always a separate
area
<eric_carlson> the Rachel Maddow player has a "transcript" button in the controller
silvia: I guess that's the only one i've seen
eric: there's no chance we will
comment on what we plan to do
... Not sure what this conversation is about. We can't possibly
require a control
... If an author puts a transcriptinto a page, the author needs
to decide whether or not it's a visible link
Silvia: I'm trying to separate blind user issues from sighted user issues. They are very different.
jf: Unhappy to hear "see it on screen" and such discussion ...
Silvia: I wanted to start by defining what the UI experience is for the sighted user
jf: We need the dom node to be able to enumerate available alternative media
silvia: I think you're agreeing with me
eric: as long as there's a
programatic association, that's all we need to satisfy the a11y
use case
... But, it's unlikely there will be a control in the default
controls that makes sense and works well for users
... Don't want a button that only shows up when there's a
transcript on a different page
jf: agree
... would be nice to have a standardized way that could be
implemented in controls, that an encounteered transcript would
bring up that button
eric: agree it would be nice, but
don't find it likely to come up with how to make that work in a
manner that wasn't confusing
... It's a much harder problem than it might seem at first
glance
ted: I think it would be a
mistake to have normative requirements in either
direction.
... There's the opportunity for all of this UI if we provide
programmatic association.
jf: So, perhaps we have a lot of
common ground
... My preference would be for native UI, but if we want to
allow ongoing expirimentation, I suppose that's OK
... There's some concern that this a longdesc by proxy
discussion, and don't want to take it there.
... Want the situation that one shouldn't have to go hunting
for the transcript
... The linkage needs to be strong, i.e. "close proximity" was
something Silvia had mentioned atone point. But how close is
that?
... I can live without native UI controls
Silvia: If we agree native
controls is not the reason for programmatic association
... My reason is that that's how I can make the screen reader
aware that a transcript is available
jf: I could imagine a situation where the sighted user turns the transcript display on and off, similar to captions
silvia: there's a big difference
between transcripts and captions
... If only the screen reader use case, we should rely on
aria
jf: so you don't buy the use case I just presented?
janina: Object to describing caption display on the video as an intended design
jf: And the discussion is still
all about display, but the not where it's rendered, it's about
consuming the alternative media
... It's important to be able to choose how to consujme the
content, primary and alternative
silvia: but won't be viewing the transcript and video at the same time as a blind user
janina: disagree
jf: disagree
silvia: don't think we have a disagreement that the blind user needs to know there's a transcript
jf: insist that's all users' need
silvia: if there's to be hiding of the transcript, it will be hidden from all
jf: why?
... this is bigger than just blind users
... my problem with Ted's proposal is that it's not
sufficiently githtly integrated. We could end up with orphaned
content, easily.
ted: two things ...
... agree it would be a mistake to create a programmatic
association that assumes it's forever only for a11y
... goal should be that we want to bring sr user to parity with
sighted user in access to transcript
... on the other hand, hiding the transcript makes it
inaccessible to the sighted user
... aria-[something] would suggest only for a11y
... disagree about the copy-paste scenario ...
... any method if transcript is elsewhere in the dom is going
to be a problem
... reason the copy-paste is a problem is exactly because
they're not contiguous in the dom necessarily
Silvia: 92473# you have that zakim code?
jf: prefer a dedicated name
because it will be much clearer than <div>
... It's not perfect, but it gets us to that
... a random container, iframe, etc., too much possibility to
lose the association
<Zakim> janina, you wanted to say that a blind user might well read transcript while viewing the video--with a refreshable braille display
silvia: sorry i dropped, want to
summarize what i think i understand from the scribing ...
... copy-paste will be difficult however
jf: so how best to minimize the
problem?
... If you're looking at source and find something called
<transcript>, much liklier to copy-paste all the way
through </transcript> -- much more easily than div plus
id, etc
silvia: may help slightly for
copy-past issue
... want to try and bil down to the core issues
... #1 when visible on page -- only people who want to hear it
at the point of getting to the video
... #2 When we want to make sure that copying the video
includes copying the transcript -- perhaps somehow it's in the
context menu?
... could even be a hash offset if transcript is right on
page
... #3 is the interactive transcript -- believe we need an
element for that
ted: I agree interactive transcripts are really interesting, but believe it's premature to specify a mechanism for them
<eric_carlson> +10
jf: so a landmark element
ted: but people can expiriment without the landmark
silvia: it's just linking to a vtt file
ted: constraining by minting an
element called transcript
... if we create an element, it should do something -- not just
be a placeholder
jf: want to etease this
apart
... what's the downside if it is only a placeholder
... but there is the available scenario that we do know that
copy-paste reduces orphaning problem
ted: reduces it only slightly
jf: something is better than nothing, no?
<silvia> <transcript mediagroup="g1">
<silvia> <track src="transcript.vtt" srclang="de">
<silvia> <track src="transcript.vtt" srclang="en">
<silvia> </transcript>
jf: e.g. aside -- it's an old stage play thing
<silvia> <video mediagroup="g1" src=video controls></video>
<silvia> +
jf: if html.next wants to layer additional, great
<Zakim> janina, you wanted to ask whether there's any doubt we're going to more and more use of transcript
janina: suggest transcript very powerful for navigation and indexing especially
eric: agree, but disagree that we
create problems by not standardizing some of this now
... think it unlikely with time left for html 5.0 that we can
sufficiently well define how this element should behave
... it's complex yet subtle behavior
... a high chance we'll spec something incorrectly
... when media was first added, it's very different now because
it took time to get it all worked out
... as it happened, i implemented ev3ry version on the
way
... pointin to the live examples currently on the web, done
with flash, points out that it is doable now
... suggest it can be scripted now
... but if we spec it now we will not get it right
... and we'll be stuck with it--so strongly object to
shoe-horning it in at this point
jf: q: if we spec'd only as landmark but leaves the door open
I lost audio
<silvia> ted: creating a placeholder element will close the door on some things
<silvia> eric: the element has to have a behaviour associated
<silvia> eric: I can't change the behaviour of a created element
I can't get back in
<silvia> JF: how do I get around the orphaning problem?
I'll follow irc
<JF> scribe: JF
EG: there are differences in the way Interactive Transcripts (ITS for here on in) render
SP: there differences are in the WebVTT cues
there are styling idfferences
believe we can get around that by starting with basic interactivity and then build upon that
but agree that we shouldn't start out with half-sorted solutions
so can likely defer that to HTML.next
SP: so if we can live with that, we can close the ITS discussion for now
<silvia> silvia: let's first finalize the interactive transcript discussion
EC: agree, and we need to do more than just say we will defer it to HTML.next, we need to start the discussion now
<silvia> silvia: I think we could create a basic <transcript> element now and finalize more functionality in html.next, but I appreciate that we might now want to put a semi-done work into HTML5
so that we can start to hone in on what we mean, and experiments can start
<silvia> silvia: I can personally live with pointing ppl at JS libraries for this problem for now and solving it properly in HTML.next
<silvia> EC: let's start discussing, but not put it into HTML5
SP want to ensure that we are in agreement about defering ITS until later
<silvia> silvia: is Janina in agreement with moving the interactive transcript problem to HTML.next?
Janina, are you comfortable with that as well?
<silvia> ted: my problem with a URL on the video element is that that would duplicate URLS when we have it on-page as well
<janina> I can live with moving interactive to .next
<silvia> ted: another problem is that the page's url may not be defined at the time of creation of the page, so it's fragile
<silvia> ted: have to leave, sorry
<silvia> JF: shall we stop here, go back to email and meet again
<silvia> eric/silvia: we've made progress, so yes
<janina> I'll work with Michael to move these minutes to the TF page
<silvia> JF: hoping to get more time out of the chairs so we can resolve this
<janina> rrsagent make minutes
<silvia> JF: maybe meet this week Friday
<janina> Yes.
<silvia> silvia: I'll write a summary email, please chip into the discussion
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/display in the video/display in the video controls/ Succeeded: s/taht/that/ Succeeded: s/?me telepathy...// Found Scribe: janina Inferring ScribeNick: janina Found Scribe: JF Inferring ScribeNick: JF Scribes: janina, JF ScribeNicks: janina, JF WARNING: No "Topic:" lines found. Default Present: JF, silvia, hober, +1.408.823.aaaa, janina, Eric Present: JF silvia hober +1.408.823.aaaa janina Eric WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 05 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/05-pf-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]