SV_MEETING_TITLE -- 11 May 2012

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

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> <a href=transcript.html>Transcript for the video</a>

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> <a href=transcript.doc>Transcript for the video</a>

chls: we don't need the same quality solution for edge cases that we need for the naive case

<JF> <a href=transcript.html>Transcript for the video</a>

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> <a href=transcript.doc>Transcript for the video</a>

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> Transcript for the video

silvia: prefer not because might need a list of links

chls: so, three transcripts -- how to distinguish between them?

<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>

<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

<chaals> [Taking things away from the normal browser isn't that flash either]

<JF> <option src=transcript_en.doc srclang="EN">English Transcript</option>

<JF> <option src=transcript_de.doc srclang="DE">German Transcript</option>

<JF> I can do that

rsagent, make minutes

- DRAFT -

SV_MEETING_TITLE

11 May 2012

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output