HTML-A11Y teleconference -- 10 May 2012

<JF> ah, cool, we can use a11y?

<janina> Looks like!

<JF> as in a11y# ?

<JF> dialing in now...

<janina> Waiting for you!

<janina> Scribe: Janina_Sajka

<janina> agenda: this

<janina> Chaas, are you dialing in? We're on Zakim 2119#

<chaals> thanks.

<chaals> I joined to find out.

<janina> There's a new CP on the floor, though!

<JF> http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP

<JF> just in case chaals hasn't seen it

<janina> Of course, if Silvia doesn't wake up and grab some coffee, this may b a short meeting after all!

<silvia> Hi everyone

<silvia> sorry, I just found the channel

<janina> Hi, Silvia, code is 2119#

<JF> dial in code is a11y#

<janina> Or you can SIP 002119@voip.w3.org

<silvia> phone number?

<janina> U.S. +1.617.761.6200

<silvia> thanks

<janina> scribe: janina

Time Tracks, Transcripts, and Issue-194

jf: Background from the F2F just concluded
... Discussion with Ted started over dinner
... I thanked him for his research paper

sp: I helped him a bit with that
... He wrote it all up

jf: So thanks also to you!

sp: I'm still of the mind that we haven't thought it all through sufficiently yet

jf: That's also the critical thing for me. We shouldn't be deferring this to .next
... Not so concerned whether we get it over first LC or second LC, but we need it in this spec

sp: I'm most fussed over getting it right and not so much as whether it's this rev or .next

chls: I'd take a middle path, we need to go the right direction ...

<JF> JS: the more I have been thinking about this, less worried about the mechanism and more about user-accomodation perspective

<JF> becoming concerned about a unified presentation of options to the end user... button creep

<JF> if we don't have a mechanism that allows for reliable grouping, we could end up with too many controls in the UI

<scribe> scribe: janina

<JF> ach ch

chls: I'm worked about having a reasonable uniform mechanism
... If we do for real come to a button creep problem, we'll have to deal with it
... But we probably won't get it right the first time
... The authoring complexity is my concern with the point-to link
... Strikes me much of this discussion is a proxy for longdesc
... The cable participants thought there was something else that was a hidden agenda when we talked about this during the F2F, which kept them out of the discussion
... I heard that in a side conversation

<JF> +1 to the perception that the initial discussion at the F2F was an @longdesc proxy discussion

chls: There won't be that many really full presentations--except large movie sites, government,

janina: Also education

sp: Which proposal are you referring to?

chls: The design pattern of pointing to a link external to the video element, as opposed to something inside it

jf: I would echo that as well
... The proposal that Ted was actioned to write would have an idref pointing to a uri
... As we discussed this more and more, many of us, especially a11y, came to like the tracks proposal best
... seemed simple and self-contained

sp: Superficially it's clearly that attractive
... Because it can be any format, pdf, odf, docx, daisy, it's more like a longdesc
... Is supposed to be a defined format
... Files that we want renedered on page, as well as those that we might buttons for, etc
... this makes my mind explode as to how to author, how to develop the implementation, etc
... There's no extra screen region to refer to outside the video element
... That's why i became so unhappy when I saw this
... So I backed off to basics ...
... The transcript doesn't require the video, you can consume it on browsers that can't render video/audio
... That's how I came up with the element outside the video element
... How we render, how we do the ui, we still need to work it all out

jf: My concern is still the copy and paste part

sp: but that's not how people embed videos

jf: Tip of the hat to youtube for figuring out a good way to do that
... But will that be the only model?
... Just concerned that the authoring pattern be very clear

sp: I appreciate the concern, but as a well developer, when I copy functionality to another page, I simply make sure I get it all
... All the sites I've seen that publish video provide a way, either iframe or a code segment that is selected and copied
... even now it includes more than the video element, title for instance

chls: ... looking at the tracks proposal
... Not sure how transcript in tracks, with 0 time ... how is that handled
... rendering into video space is probably not such a big issue, because people who can't see the video won't care about rendered video
... also not so concerned about linking -- we know how to handle links
... do exactly what Opera did with longdesc -- that does seem to work
... Our experience is that it works tolerably well

sp: At least in webvtt at the moment, we require start and end, so if it's only 0 it will sit there in a single queue
... js will have to do something with it--no rendering implied
... But then we restrict ourselves to transcript either in webvtt or ttml, but not the other file formats
... It doesn't give us rendering, what do we expect the web browser to do with it?

<JF> +1 to overt restrictions on trnscript file formats

chls: Agree that it restricts us and makes a mess because a lot of docs won't be available in that format
... we have the kind attrib to define what to do

chls: It could link out to a doc, pdf, etc

jf: Also a web developer--how I pay my bills--and work with a building full of other developers

chls: These still do silly things, hence my concern. We need to make the right thing simple and clear

jf: That's why I'm looking at the authoring pattern, not so much the underlying mechanism

sp: How then is the transcript rendered when it's inside the video element?

jf: via js, i suppose?
... Will work one way on my phone and differently on my laptop

sp: video element, if we put stuff in there, affects a defined region of the screen.
... In recent years people have been backing off from too many buttons inside video
... what seems to be of issue is that we're only talking, so far, of one way of dealing with transcripts, whereas there are two other ways as well
... We have the not on screen but programatically discoverable transcript ...
... everything inside video is passed away by the browser--it's not in the dom

<JF> <p>Lorum Ipsum X 15 paragraphs</p>

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

sp: we have all the techniques we need for associating transcript and video, even when it's not inside the element

jf: still concerned about the association between video and transcript when it's outside the element

sp: same for labels
... it's only that it makes sense for them to be next to each other

chls: I'm not so sure that the hidden discussion from i204 is unrelated to this
... we seem to be building something fragile -- when dealing with hiding stuff
... relying on a link to content that's somewhere else is the fragile part that's still problematic -- longdesc like

cls: people are still shipping display=none and 1pixel gifs with alt, etc

chls: to my certain knowledge, WAI has been working on solving this for 15 years
... I think that an approach which relies on techniques to make hidden text accessible is a very fragile one

We'll wait for you!

Silvia, from Zakim?

<silvia> yes - it's restricted

<silvia> call center is restricted at this time

<chaals> call center?

<chaals> not conference?

<silvia> the pass code is not valid

<chaals> i.e. is zakim telling you this?

<chaals> aha

Silvia, use 26631#

<silvia> pk

zkim, ??P3 is Janina

sp: q about fragility? why if in video element? don't we have the same problem however we do it?

chls: in the elemtn we rely on browsers not doing stupid things
... outside, we rely on authors not doing stupid things
... experience suggests that even a million authors doing this right, there will still be masses of authors doing this wrong

sp: we still want rendering on the page, no?

[agreement in the room]

jf: I suspect we're thinking the link to transcript would be displayed as a control
... Citing experience with dlink which has not been successful

sp: why are we repeating dlink?

jf: that is what relying on a text link is doing

[process discussion on next steps in view that this was to be done May 11 according to F2F]

jf: any reason transcript element can't be child of video?

sp: yes, because it restricts us to the screen space assigned to video
... my approach gives us anothr view port

chls: agree with concern on rendering model
... one use case video not even rendered

janina: pointing out that the no video use case isn't just disability use case

chls: side by side still sensible rendering

chls; if has timing, no problem

chls: still not convinced that it's too hard to mix this in and that it requires external definition
... e.g. pasting a word doc into an iframe rendered side by side with the video
... of course it's more readable if read without the timing ml
... but harder to render in sync

sp; we should handle all types of transcripts in a uniform manner

jf: don't think we're that far apart

janina +1 to not so far apart

jf: still fighting to preserve simple and clear author experience

<chaals> sp: my concern is that you wouldn't be able to render the transcript in parallel with the video

sp: my proposal is similar to the signed translation being in a separate video and the video description in a separate audio element

<chaals> jf: use case is to save the transcript, and read later.

<chaals> [I agree that it should be possible to render side-by-side. I don't see how any of the proposals get away from "the web developer has to make that feasible" (on the basis that browsers getting into hcking the display of pages is a pretty fragile way to work)]

<chaals> [I am concerned about the issue of whether the transcript data should be inside or outside, but I may be convinced that having it outside is workable (I would have to "evolve my position" to get there...)]

<silvia> we're considering another call tomorrow same time

<silvia> does that work for you?

<JF> chaals, we are going to try and reconvene at the same time tomorrow

<chaals> [I am really concerned about building on top of a bit of page content, because I believe that is repeating the D-link experiment. People *will* try to hide the text (which means you lose any benefit over the original longdesc approach), and will get it wrong...]

<silvia> I'll think this through for tomorrow...

<chaals> I'll try for tomorrow.

<chaals> [I am not that fussed about the colour of the bike shed. There are many ways to make a colour scheme consistent in my bike shed]

<chaals> [Oh. I mean that there are multiple ways to get consistency while tossing around attribute/element, special name or re-use something, ...]

rrsagent make minutes

- DRAFT -

HTML-A11Y teleconference

10 May 2012

Attendees

Contents

Time Tracks, Transcripts, and Issue-194

Summary of Action Items

Scribe.perl diagnostic output