W3C

- DRAFT -

SV_MEETING_TITLE

05 Jun 2012

See also: IRC log

Attendees

Present
JF, silvia, hober, +1.408.823.aaaa, janina, Eric
Regrets
Chair
jf
Scribe
janina, JF

Contents


<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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/06/06 00:17:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]