- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 28 Jul 2011 13:20:54 +1000
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
As discussed in today's media subgroup meeting, I have registered a bug on the audio accessibility issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13400 . Regards, Silvia. On Thu, Jul 21, 2011 at 9:08 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Hi all, > > I have some feedback on this inline, but in general I think this is > good feedback that we should put in a bug for the HTML WG to fix on > the spec. > > Cheers, > Silvia. > > > On Thu, Jul 21, 2011 at 7:21 AM, Janina Sajka <janina@rednote.net> wrote: >> I believe the attached should be shared on list. >> >> Janina >> >> >> >> ---------- Forwarded message ---------- >> From: Geoff Freed <geoff_freed@wgbh.org> >> To: Janina Sajka <janina@rednote.net> >> Date: Wed, 20 Jul 2011 14:25:36 -0400 >> >> Hi, Janina: >> >> Below are some suggested changes to the video, audio and track elementS. I’ve pasted in the original text followed by the proposed change, but let me know if anything isn’t clear or if you want more info. I may have time to go over the spec again before July 27, but I can’t guarantee. >> >> Thanks for asking me to review these sections. >> Geoff/NCAM >> >> ====== >> >> >> -- VIDEO ELEMENT (http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-video-element) >> 1. current text: >> To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks, audio description tracks, or sign-language overlays) into their media streams. >> >> suggested change: >> To make video content accessible to users who are blind, visually impaired, deaf or hard of hearing, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or accessibility aids (such as caption or subtitle tracks, audio-description tracks, or sign-language overlays) into their media streams. >> >> >> 2. current text: >> When a video element whose media resource has a video channel is potentially playing, it represents the frame of video at the continuously increasing "current" position. When the current playback position changes such that the last frame rendered is no longer the frame corresponding to the current playback position in the video, the new frame must be rendered. Similarly, any audio associated with the media resource must, if played, be played synchronized with the current playback position, at the element's effective media volume. >> >> suggested change: >> When a video element whose media resource has a video channel is potentially playing, it represents the frame of video at the continuously increasing "current" position. When the current playback position changes such that the last frame rendered is no longer the frame corresponding to the current playback position in the video, the new frame must be rendered. Similarly, any audio, text or other tracks associated with the media resource must, if played, be played synchronized with the current playback position, at the element's effective media volume. >> >> >> 3. current text: >> When a video element is paused at any other position, and the media resource has a video channel, the element represents the frame of video corresponding to the current playback position, or, if that is not yet available (e.g. because the video is seeking or buffering), the last frame of the video to have been rendered. >> >> suggested change: >> When a video element is paused at any other position, and the media resource has a video channel, the element represents the frame of video corresponding to the current playback position, or, if that is not yet available (e.g. because the video is seeking or buffering), the last frame of the video to have been rendered. If synchronized text (e.g., captions or subtitles) or sign-language tracks are present, those tracks must be represented in the paused frame as well. >> >> >> 4. current text: >> User agents should provide controls to enable or disable the display of closed captions, audio description tracks, and other additional data associated with the video stream, though such features should, again, not interfere with the page's normal rendering. >> >> suggested change: >> User agents must provide controls to enable or disable the display of closed captions, audio description tracks, and other additional data associated with the video stream, though such features should, again, not interfere with the page's normal rendering. >> > > I'd say: If such features are available, user agents must provide controls... > > >> 5. current text: >> User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent. >> >> suggested change: >> User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). Captions, subtitles or other additional visual tracks must remain available and visible at all times. As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent. >> >> >> >> -- AUDIO ELEMENT (http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-audio-element) >> 1. current text: >> To make audio content accessible to the deaf or to those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as transcriptions) into their media streams. >> >> suggested change: >> To make audio content accessible to users who are deaf or hard of hearing, or to those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or accessibility aids (such as caption or subtitle tracks, audio-description tracks, or sign-language overlays) into their media streams. >> > > Sign-language overlays make no sense for the audio element, because it > has no visual component. Audio-descriptions tracks make no sense for > the audio element either, because there is no visual component to > describe. Similarly, caption and subtitle tracks make only limited > sense for the audio element, because there is no visual display onto > which the text would be rendered. They could only be used through > JavaScript which can extract them and display as a transcription next > to the audio element. > > There are two solutions for making audio resources accessible by > default: one is to have an audio resource with embedded > captions/subtitles and put it in a video element. Then, the > captions/subtitles will be displayed even through there is no other > visual component. The other is the use of the @transcript attribute > that we have suggested: provide the audio resource in the audio > element and link to a full-text transcript (without time markers) in > the @transcript attribute. The latter actually makes the most sense > for hearing-impaired users, because they really don't need to wait for > captions to display chunk by chunk and will find it generally more > useful to be able to scan the transcript. > > So, instead of the original text, we should probably suggest to add a > sentence that when audio resources are provided with embedded > accessibility aids (such as captions or subtitles), it is recommended > to publish them through the video element, which will provide a visual > display area for the captions/subtitles. In addition, we should > continue to push for the @transcript attribute. > > >> -- TRACK ELEMENT (http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-track-element) >> 1. current text: >> (from the @kind table) keyword: subtitles / Transcription or translation of the dialogue, suitable for when the sound is available but not understood (e.g. because the user does not understand the language of the media resource's soundtrack). Displayed over the video. >> >> suggested change: >> Translation of the dialogue, suitable for when the sound is available but not understood (e.g., because the user does not understand the language of the media resource's soundtrack). >> > > Let's not remove the "Displayed over the video." part. That is > important to keep, so we have a default display. > > >> 2. current text: >> (from the @kind table) keyword: captions / Transcription or translation of the dialogue, sound effects, relevant musical cues, and other relevant audio information, suitable for when the soundtrack is unavailable (e.g. because it is muted or because the user is deaf). Displayed over the video; labeled as appropriate for the hard-of-hearing. >> >> suggested change: >> Transcription of the dialogue, sound effects, relevant musical cues, and other relevant non-speech audio information, suitable for when the soundtrack is unavailable (e.g., because it is muted) or cannot be perceived (e.g., because the user is deaf or hard-of-hearing). >> > > Again, let's not remove the "Displayed over the video" part. > > >> 3. current text: >> (from the @kind table) keyword: descriptions / Textual descriptions of the video component of the media resource, intended for audio synthesis when the visual component is unavailable (e.g. because the user is interacting with the application without a screen while driving, or because the user is blind). Synthesized as separate audio track. >> >> suggested change: >> Descriptions of the video component of the media resource, intended for playback or audio synthesis when the visual component is unavailable or cannot be perceived (e.g., because the user is blind or visually impaired). May be a pre-recorded, discrete audio track or may be synthesized at the time of playback as a discrete audio track. >> > > There is a difference between the text descriptions and audio > descriptions in their handling in the browser. We cannot mix them up > in a single @kind. The track element exists only for text tracks, so > the original text is correct to only reference "textual descriptions". > If we have pre-recorded audio transcriptions, then they need to be > provided through the multitrack API at > http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#media-resources-with-multiple-media-tracks > . This is a totally separate use case. > > I suggest, however, we change the order of the use cases given, since > the blind use case is indeed the important and more outstanding one. > Also, the "separate audio track" is not correct. So how about this: > > suggested change: > Textual descriptions of the video component of the media resource, > intended for audio synthesis when the visual component cannot be > perceived (e.g. because the user is blind or visually impaired) or the > visual component is unavailable (e.g. because the user is interacting > with the application eyes-off or without a screen). Synthesized to > audio by a screen reader or other audio synthesis system. > > >> >> On 7/15/11 6:14 PM, "Janina Sajka" <janina@rednote.net> wrote: >> >> Dear Geoff: >> >> As you're aware, the HTML 5 specifications are now in Last Call Working >> Draft review at the W3C. This is a very large specification, running >> some 1200 pages when printed. So, in order to achieve a complete review >> for accessibility, we're parcelling out sections of the specification >> and asking individuals to provide comments on those sections. >> >> If you care to accept, you're one of the people who've been nominated >> to review: >> >> Media Elements >> http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#media-elements >> >> Video Element >> http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-video-element >> >> Audio Element >> http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-audio-element >> >> Source Element >> http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-source-element >> >> Track Element >> http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-track-element >> >> We're asking you to review these sections and advise us of any >> accessibility barriers that we need to flag as bugs. We need to file >> bugs no later than August 3, so it would be most helpful to have your >> review comments by July 27. Could you please let us know by return email >> if you can do that? >> >> Thank you. >> >> Janina >> >> >> -- >> >> Janina Sajka, Phone: +1.443.300.2200 >> sip:janina@asterisk.rednote.net >> >> 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 Thursday, 28 July 2011 03:21:52 UTC