Media Subteam Minutes for 10 May

Minutes from the HTML-A11Y Task Force Media Subteam on 10 May are provided below in text and are available as hypertext at:

http://www.w3.org/2012/05/10-media-minutes.html


   W3C

                                                           - DRAFT -

                                                    HTML-A11Y teleconference

10 May 2012

   See also: IRC log

Attendees

   Present
          JF, silvia, chaals, janina

   Regrets
   Chair
          John_Foliot

   Scribe
          Janina_Sajka, janina

Contents

     * Topics
         1. Time Tracks, Transcripts, and Issue-194
     * Summary of Action Items
     __________________________________________________________________________________________________________________

   <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

   <JF> <foobar kind="transcript">

   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> <video id=v1 src=video.mp4></video>

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

   <JF> <transcript for=v1 id=t1>

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

   <JF> </transcript>

   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

Summary of Action Items

   [End of minutes]
     __________________________________________________________________________________________________________________

Scribes: janina
Present: JF silvia chaals janina

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Thursday, 10 May 2012 23:15:36 UTC