See also: IRC log
<trackbot> Date: 04 April 2013
<chaals> Chaals: anyone prepared to Scribe
<LJWatson> scribe: Léonie Watson
<LJWatson> CMN: Welcome to Mark.
<LJWatson> JB: Mark will be staff contact specifically for the HTML A11y TF.
<LJWatson> MS: Would welcome anyone who'd like to schedule a call with me to give me some background.
<LJWatson> JB: We're thrilled you're here.
<LJWatson> +1 Welcome to Mark
<LJWatson> Welcomes and introductions from members of the TF present on the call.
<LJWatson> CMN: We have a WAI IG review in progress. Roughly 10 open bugs. Some are tricky.
<LJWatson> CMN: Three in particular - One suggests raising longdesc from "should" to "must", another suggests UA behaviour when the longdesc is pointless, and a third discusses images like stock photography.
<LJWatson> JS: Could we filter by enhancement versus what HTML4 already provided?
<LJWatson> CMN: In the days of HTML4 specs tended to be more loose. Substantive issues tend to be the things left undefined then.
<LJWatson> CMN: The presentation role may be a topic at the F2F. Paul requests that topic suggestions are sent to the HTML WG, topics for Web App Sec should go to that WG.
<LJWatson> PC: When would you like to focus on a11y topics, so it fits with time on PF topics?
<LJWatson> JS: PF has a fairly full agenda.
<LJWatson> JS: We'll know more closer to the meeting time.
<LJWatson> PC: Registeration closes tomorrow.
<LJWatson> JS: I should be more informed next week.
<JF> Suggest revisiting the transcript issue with the larger group
<LJWatson> PC; Sent a note to our host, had a request from the Media TF to break out discussions on topics that might not involve everyone.
<LJWatson> PC: Janina could consider adding topics to the Tuesday agenda, then looking at a breakout session?
<LJWatson> CMN: Do you run your agenda unconference style?
<LJWatson> PC: Yes. Given that most PF people won't be there until Wednesday, it's important for us to know what a11y topics need to be discussed.
<LJWatson> CMN: I'll be there from Tuesday 9am, so envisage actively taking part in that process.
<LJWatson> CMN: Process for producing TF deliverables published on the wiki. Please take a look and feedback.
<LJWatson> MW: The idea of the Encrypted Media Extension is to produce a common API.
<JF> scribe: JF
<chaals> scribe: JohnF
<JF> MW: the EME is all in the context of the <video> element in HTML5
<JF> MW: there have been a number of discussions WRT to captions and DRM
<JF> not much mentioned in this topic
<JF> do not have any encrypted captions at this time, but there have been some questions around captions inside of the media wrapper
<chaals> acj john_foliot
<chaals> unmute john_foliot
<chaals> JF: Are transcripts and audio descriptions going to be things that content owners will want to have protected?
<chaals> JF: My concern is that we don't arrive at the last minute and discover tehre are lots of questions - so I am looking for some help in formulating it.
<chaals> MW: [earlier answer] Don't know. THink it is important for people who want to know that to join teh technical work.
<JF> JS: wanted to explore that idea, but from a slightly different perspective
<JF> suggest we revisit the existing specifications to understand terminology
<JF> appears that captions and subtitles are used interchangibly
<JF> seemed that very few people had an understanding of the other types of requirements (extended descriptions, etc.)
<JF> so we should be careful that we are using correct terminology
<JF> JS: we should also check back with our contacts who develop these types of alternatives to see if this topic has hit their radar as well
<JF> JS: did have one other range of concerns, wrt the controls, and want to confirm that they remain outside of this discussion
<JF> MW: correct, this should have no impact on the controls
<JF> this should be more clearly called out in the EME spec
<JF> MW: there is the ability to apply CSS transformations to <video>, but that might be restricted in DRM'ed content
<chaals> [/me notes that there are also users who are trying to enforce "moral right" - restrictions on use of their content, and we can expect them to consider this a feature]
<JF> JB: in some settings, DRM settings have been known to interpret Screen Readers as an "attack"
<JF> what I am hearing here however is that this is likely not the case here. Looking to get some form of confirmation that this is not something we would be concerned with here
<JF> MW: not convinced of this yet, as I do not have a full understanding of the SR technologies
<JF> JB: if it turns out that this is a risk, it will become a high priority issue for us to address
<JF> so making sure that access to caption and video description streams is important
<JF> MW: to my understanding, those devices need access to the raw video stream?
<JF> JS: historic problem arose from accessing the text that had been encrypted
<JF> if a SR is your "eyes" and that text was encrypted, then the screen reader was perceived as an attack
<JF> I don't see this as the same issue if the data is a video stream, but if the alternative representations are encrytped then the issues will likely remain
<JF> we have some bugs in general about media controls
<JF> MW: back to the screen readers, I think there are 3 tech. possibilities" 1) delivered in the clear, 2) within the multi-plex delivery, 3) encrypted captions could be rendered in the DRM system to be rendered on the screen (??)
<JF> we have not address those in the spec at this time
<JF> the first 2 appear clear, and to date no-one has come forward with a request for the third
<JF> MW: if we feel that in the future that it does surface, then we would need to look at that
<Zakim> chaals, you wanted to ask how the spec handles different requirements on different parts of content - does it allow for tracks with different CDMs?
<JF> However as Janina has noted, it would be a lot simpler if the support files remained in the clear
<JF> DM: can't imagine why content owners wouldn't want to encrypt those files
<JF> CMM: there are a lot of content owners who don't do this today
<JF> MW: this is the case at netflix, where videos are encrypted but not caption files
<JF> PC: this might be a topic to add to the F2F agenda
<JF> the EME folk have asked for a 90 minute slot
<JF> thus asking these questions to the larger group may surface other responses [sic]
<JF> CMM: don't know why we can't squeeze these into the same 90 minutes
<JF> PC: a lot of the existing EME bugs are quite complex
<JF> CMM: if you have the video element and a track element, then can you apply the DRM to the media and not the track?
<JF> MW: this is the idea. This might need to be made clearer in the draft spec
<JF> JS: David macDonald's question is quite valid
<JF> we have had this problem in the past
<paulc> I need to go to get ready to Chair the WG meeting
<JF> CMM: reached the end. Would like to thank Mark for coming to explain this topic further
<JF> there are a large number of things still to be addressed, so please follow the mailing list carefully
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Léonie Watson Found Scribe: JF Found Scribe: JohnF WARNING: 0 scribe lines found (out of 331 total lines.) Are you sure you specified a correct ScribeNick? Scribes: Léonie Watson, JF, JohnF WARNING: No "Present: ... " found! Possibly Present: Apple CMM CMN DM David_ David_MacDonald IPcaller IanPouncey JB JF JS John_Foliot Judy LJWatson Leonie MS MW MarkS Mark_Sadecki MichaelC Michael_Cooper Microsoft P12 P24 PC Steve aaaa aabb chaals chaals1 darobin davidb hober inserted janina markw paulc smiles trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/04-html-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]