- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 4 Mar 2010 08:11:50 +1100
- To: John Foliot <jfoliot@stanford.edu>
- Cc: Matt May <mattmay@adobe.com>, Sam Ruby <rubys@intertwingly.net>, HTML WG <public-html@w3.org>
On Thu, Mar 4, 2010 at 4:59 AM, John Foliot <jfoliot@stanford.edu> wrote: > Matt May wrote: >> >> On Mar 3, 2010, at 9:58 AM, Sam Ruby wrote: >> > Discussion has died down >> >> I wouldn't say it's died down at all. It's just moved to public-html- >> a11y. Until the summary discussion bubbled up over the last 2 weeks, it >> was the #1 topic, and the group was making progress. > > Agreed. Some concrete progress is being made, and 2 work efforts that can > be reviewed are at: > > * Media TextAssociations: > http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations > * Media MultitrackAPI: > http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI > > Some discussion has ensued around these documents, although the final > status remains fairly fluid. Michael(tm) Smith has prepared interim > surveys on these proposals very late yesterday (I received my email @ > 22:30 Pacific Time), and some discussion has resurfaced around those > postings. Generally the MultitrackAPI is being well received; the Media > TextAssociations discussions are currently focused on supporting > time-stamp formats: there will need to be continued discussion here, but > the *trend* seems to be favoring .SRT files for legacy/backwards usage, > and a move towards a profiled approach to DFXP; the concern is that DFXP > is likely too "large" to support out of the box, so a stripped down > version (or two) is likely the next step. Work here is also very fluid, > with no identified timeline/deadline at this point. I suspect we will > need to address that fairly quickly, and will seek to bring it up on > Thursday's a11y Task Force call. The hope is that within the next two weeks these two change proposals will be agreeable within the Task Force and we can move them into the HTML WG. So, a deadline of 5th April is not unrealistic for *progress* on issue-9. However, it has to be understood that these two change proposals are only a start towards media accessibility. They are the most important techniques that the browser vendors will need to implement next to gain basic media accessibility. There will be a need for more techniques, but we will need to gain some experiences with these implementations first before moving on. So, even with these two change proposals coming in, I would suspect we should not close Issue-9, but use it to continue monitoring progress on media accessibility features. Best Regards, Silvia.
Received on Wednesday, 3 March 2010 21:12:48 UTC