See also: IRC log
trackbot start meeting
<JF> silvia, Janina has to request a room first'
OK. Our good old code 2119#
<scribe> scribe: janina
silvia: worked some more, not
enough, on the doc
... tried to address concerns from yesterday
<JF> http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP
[looking at patterns in silvia's cp]
jf: Looking at the first pattern ...
silvia: putting track within div
doesn't have a meaning at this time
... an element inside on div would be legacy problem
<silvia> <video id=v1 src=video.mp4></video>
<silvia> <transcript for=v1 id=t1>
<silvia> <track src=transcript1.vtt srclang=en default>
<silvia> <track src=transcript2.vtt srclang=de>
<silvia> </transcript>
jf: What's the discovery mechanism in that pattern?
silvia: @for
... how the rendering happens needs discussion
... rendering is going to be an issue regardless the underlying
associating mechanism
Yo!
chls: no doubt we can meet all
the use cases any number of ways
... still concerned mainly about authoring patterns
... Seems browsers learn to get this right faster than authors
do
... something like the worst 50% of authors more lkely than
browsers to break things
... if we expect them to get all the particulars correctly
ligned up
jf: wants to speak to this as
well ...
... looking at use case #2 ...
<silvia> <video id=v1 src=video.mp4></video>
<silvia> <transcript for=v1 id=t1>
<silvia> <a href=transcript.html>Transcript for the video</a>
<silvia> </transcript>
jf: That some percentage of
authors will push the transcript away from the video element,
even push it off screen
... we're seeing more and more of these problems today--we have
so many different ways to hide content
... This is why I think we need to solidly keep transcript with
video
silvia: so, before addressing this, what's today's preferred hiding mechanism
jf: most robust way today is off-screen
jf using css
jf: but focusable content in that off-screen creates problems for sighted keyboard users
<Zakim> chaals, you wanted to respond... too
chls: so, sensible guidance says:
"don't hide it."
... but then your customer says: "hide it somehow"
... it's the browser/at that makes things discoverable, e.g.
jfw with longdesc
... the best people get it right, and more right than the
browsers even
... average developer will likely get it wrong because all
these techniques have issues
... so, what's suggested for browsers to do?
... many hiding techniques were for making pix of fonts
a11y
... of course, this handled only one area of a11y -- didn't
handle high contrast need, for instance
... the solution that hides it until you tab to it is messy and
definitely breaks page layout
jf: whatever mechanism we come up with needs to put a button in the controls
silvia: back to the hiding
problem ....
... want to address the request to keep transcript with the
video element ...
... the transcript needs to be navigable
... think hiding is orthogonal
janina: suggesting an omnibus
"alternate renderings" button
... noting that users who need certain alt types will configure
to auto select them
silvia: working on chrome
buttons, we haven't found an optimum solution yet
... regardless, how these are 'buttoned' is not for the spec to
define, though guidance may be ok
<Zakim> chaals, you wanted to say I think we can make the buttons and text navigable in any model
chls: suspect we may never find
an optimum solution for rendering availability -- buttons
...
... closest we get is workable solutions, and every browser's
is different
... we shouldn't prescribe
... suggest we should be trying to provide a way for browsers
to put some kind of button before the user rather than
hardcoding a proximate on screen rendering
... relying on users needing to upgrade browsers in the short
term may be worth it to get this right for the future
<Zakim> JF, you wanted to say that the activation mechanism for showing/hiding the transcript is what we need to deal with
jf: agree that there may be an
misunderstanding here
... want to go back to the downloadable transcript use case
...
... i'm concerned about what's the mechanism that allows the
user to do that?
... the browsers that have taken the trouble to indicate
longdesc is available have done a good job of this
silvia: want to avoid solutions
that require js
... agree not to rely on developers to render
... i definitely want the browser to render, with sync if
available
<chaals> [Yeah, I think we're on the same page about wanting the browser to handle the rendering as far as possible]
<Zakim> chaals, you wanted to say I'd take the job of teaching authors who have interactive transcripts over the job of teaching authors who have some kind of transcript...
chls: noting web intents is
relevant here -- to enable an ordinary web page to get the
player for the media type to render
... the people who most need the noninteractive transcript will
survive without video rendering
<silvia> <video id=v1 src=video.mp4></video>
<silvia> <transcript for=v1 id=t1>
<silvia> <a href=transcript.doc>Transcript for the video</a>
<silvia> </transcript>
chls: we don't need the same quality solution for edge cases that we need for the naive case
<JF> <video id=v1 src=video.mp4></video>
<JF> <transcript for=v1 id=t1 class="CSS_OFF_SCREEN">
<JF> <a href=transcript.html>Transcript for the video</a>
<JF> </transcript>
jf: do I understand the transcript element is akin to aside or landmark?
silvia: yes
jf: so the association to video is performed by the transcript element ...
<silvia> <video id=v1 transcript=t1 src=video.mp4></video>
<silvia> <transcript id=t1>
<silvia> <a href=transcript.doc>Transcript for the video</a>
<silvia> </transcript>
jf: still concerned about the client who wants me to hide it
<Zakim> JF, you wanted to return to the authoring pattern
silvia: if hidden then only
discoverable to screen reader users, but that's not useful to
sighted users
... to make it available for sighted users would need a button
on video
... what about a transcript attrib on video element?
... sounds like you'd prefer attrib? would be ok by me
jf: would we be able to expose
that in the controls?
... wcan we make it default behavior?
silvia: yes, either way, and we can recommend the behavior
jf: rfc2119 should?
silvia: that's all we can do with controls
chls: even if it's rfc2119 must we can't force browsers
silvia: rendering by browsers is beyond this spec
<JF> <video id=v1 transcript=t1 src=video.mp4></video>
<JF> <transcript id=t1 src=transcript.doc>
<JF> Transcript for the video
<JF> </transcript>
silvia: prefer not because might need a list of links
chls: so, three transcripts -- how to distinguish between them?
<JF> <video id=v1 transcript=t1 src=video.mp4></video>
<JF> <transcript id=t1>
<JF> <track src=transcript_en.doc srclang="EN">
<JF> <track src=transcript_de.doc srclang="DE">
<JF> </transcript>
<chaals> [JF: better to reuse hreflang here]
silvia: don't think the track
will work
... want to keep track semantics -- so don't want pdf, etc in
track
... the hidden tab problem is generic not specific to this
jf: but we shouldn't perpetuate the generic problem
<Zakim> chaals, you wanted to say that the indirected link increases the surface of the problem, compared to something which does not rely on something that is by default hidden in the
silvia: suggest avoiding the
keyboard focus problem shouldn't prevent us from solving
transcript in a uniform manner
... anything else was requiring rendering inside the video
element
jf: can't speak for the tf on this, but solving one problem by perpetuating another may not be acceptable
Bring on ARIA Landmarks!
give me back html 2.0! <grin>
<JF> <transcript id=t1>
<JF> <option src=transcript_en.doc srclang="EN">
<JF> <option src=transcript_de.doc srclang="DE">
<JF> </transcript>
<chaals> [/me doesn't like using option - I'd rather put the links inside the transcript container and hide them a la object...]
<chaals> [if we are getting the video player to pick up the links anyway]
<chaals> [(option just seems a bit off to one side for me)]
<silvia> aria-onlyAT
<JF> <div hidden aria-hidden="false">
<chaals> [Taking things away from the normal browser isn't that flash either]
<JF> <video id=v1 transcript=t1 src=video.mp4></video>
<JF> <transcript id=t1>
<JF> <TBD src=transcript_en.doc srclang="EN">
<JF> <TBD src=transcript_de.doc srclang="DE">
<JF> </transcript>
<JF> <transcript id=t1>
<JF> <option src=transcript_en.doc srclang="EN">English Transcript</option>
<JF> <option src=transcript_de.doc srclang="DE">German Transcript</option>
<JF> </transcript>
<JF> I can do that
rsagent, make 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/background/legacy/ Succeeded: s/an attrib/an element inside/ Succeeded: s/authors/something like the worst 50% of authors/ Succeeded: s/too likely/more lkely than browsers/ Succeeded: s/keyboard/sighted keyboard/ Succeeded: s/appearance/layout/ Found Scribe: janina Inferring ScribeNick: janina WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: P0 P3 UA by chaals chls element handled janina jf silvia video You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 11 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/11-media-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]