- From: Janina Sajka <janina@rednote.net>
- Date: Thu, 7 Jun 2012 11:46:29 -0400
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Resending with the correct file this time. Very sorry for the confusion! --Janina Minutes from the HTML-A11Y Task Force Media Subteam teleconference of Tuesday 5 June are provided below as text, and are available as hypertext at: http://www.w3.org/2012/06/05-html-a11y-minutes.html 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 * Topics * Summary of Action Items __________________________________________________________________________________________________________________ <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] __________________________________________________________________________________________________________________ Scribes: janina, JF Present: JF silvia hober +1.408.823.aaaa janina Eric -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Thursday, 7 June 2012 15:46:54 UTC