W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2012

Media Subteam Teleconference Minutes for 11 May

From: Janina Sajka <janina@rednote.net>
Date: Fri, 11 May 2012 19:16:39 -0400
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20120511231639.GC4315@sonata.rednote.net>
Minutes from the HTML-A11Y Task Force Media Subteam teleconference of 11 May are provided below in text and are available as hypertext at:



                                                           - DRAFT -


11 May 2012

   See also: IRC log





     * Topics
     * Summary of Action Items

   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


   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

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

   <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

Summary of Action Items

   [End of minutes]

Found Scribe: janina


Janina Sajka,	Phone:	+1.443.300.2200

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 Friday, 11 May 2012 23:17:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC