- From: Dave Singer <singer@apple.com>
- Date: Fri, 12 Oct 2007 17:37:21 -0700
At 0:30 +0000 13/10/07, Ian Hickson wrote: >On Thu, 22 Mar 2007, Dave Raggett wrote: >> >> From an accessibility perspective the proposal lacks support for >> captioning. There should be a mechanism for enabling/disabling captions >> to avoid disadvantaging people who have difficulties with hearing the >> audio. It should further be possible to control the font size for >> captions to avoid disadvantaging people who don't find small font sizes >> intelligible. I don't think that the Web Accessibility folks will find >> the fall back text to be a compelling solution, and it is no longer >> acceptable to ignore accessibility. > >I've added text to indicate that user agents should make subtitles >available to the user. I (we) agree completely that accessibility is both important and should be explicitly addressed in the spec. I don't think it makes sense to talk only about one kind, however. We've sent a previous email outlining how a user could express their accessibility needs ('i need captions'), and how source selection and/or content-specific enabling could supply them. Some content has captions 'burned in', and to get them, you need to select the content with the burned-in captions. Other systems have provision for enable-able captions, and in that case, the same soyrce serves, and it should enable the captions in response to the user's wish. I know it's ugly to have the ability to 'get captions' at two layers (HTML source selection, media player feature enablement). But captions known as such within the media player have superior characteristics to burned-in ones (e.g. they can also respond to bigger/smaller requests), but not all systems support true (non-burned-in) captions. -- David Singer Apple/QuickTime
Received on Friday, 12 October 2007 17:37:21 UTC