Re: [whatwg] Alt attribute for video and audio
On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: On Fri, Aug 14, 2009 at 9:13 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. For users who can use audio but not video, authors should either provide audio descriptions in the video file as alternative tracks, or supplemental material provided in links available to everyone near the video. For users who can use video but not audio, authors should provide subtitles, captions, or transcripts either in the video or audio file as supplemental tracks, or in supplemental materials available to everyone in links near the video. For users who can use neither video nor audio, supplemental materials are likely the best thing for an author to provide, again, in links visible to all. For users of legacy UAs that don't support these features, feature-rich alternatives such as plugins can be provided as fallback content for video and audio. Captions and subtitles can be included either directly in the media file, or scripts can manually support external resources using the cue range API. Going forward, we will probably also support dedicated formats that UAs can merge with the video to handle showing external subtitles natively. I don't see a need for an alt= attribute here. What problem would it solve that is not solved by the above solutions? There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. It seems that ARIA attributes, the title= attribute, figurelegend, and just regular UA defaults (e.g. announcing that you're on a video element) are sufficient. On Fri, 14 Aug 2009, Silvia Pfeiffer wrote: On Fri, Aug 14, 2009 at 11:09 PM, Henri Sivonenhsivo...@iki.fi wrote: I believe aria-label addresses this. Excellent. Then I haven't seen a good argument to add it. Let's not. On Fri, 14 Aug 2009, Remco wrote: Yes, I think that covers it. This also covers the most important, but apparently always ignored case: authors who don't have time for accessibility. A significant portion of web authors will not provide subtitles for every published video. Nor will they provide links to a transcript. Even if they care about accessibility, it's just not economically viable to do it. The best you can hope for is a sentence or two explaining what the video does. This also covers other non-text elements: iframe, embed, object. The only thing left is ARIA's integration with HTML. Have you had success with your draft? http://hsivonen.iki.fi/aria-html5/ I see you only had one reply to your first announcement. Will the remaining ARIA attributes be an explicit part of HTML? Will the aria- prefix be removed? ARIA is now integrated in HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alt attribute for video and audio
On Mon, 10 Aug 2009, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. For users who can use audio but not video, authors should either provide audio descriptions in the video file as alternative tracks, or supplemental material provided in links available to everyone near the video. For users who can use video but not audio, authors should provide subtitles, captions, or transcripts either in the video or audio file as supplemental tracks, or in supplemental materials available to everyone in links near the video. For users who can use neither video nor audio, supplemental materials are likely the best thing for an author to provide, again, in links visible to all. For users of legacy UAs that don't support these features, feature-rich alternatives such as plugins can be provided as fallback content for video and audio. Captions and subtitles can be included either directly in the media file, or scripts can manually support external resources using the cue range API. Going forward, we will probably also support dedicated formats that UAs can merge with the video to handle showing external subtitles natively. I don't see a need for an alt= attribute here. What problem would it solve that is not solved by the above solutions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alt attribute for video and audio
On Fri, Aug 14, 2009 at 9:13 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. For users who can use audio but not video, authors should either provide audio descriptions in the video file as alternative tracks, or supplemental material provided in links available to everyone near the video. For users who can use video but not audio, authors should provide subtitles, captions, or transcripts either in the video or audio file as supplemental tracks, or in supplemental materials available to everyone in links near the video. For users who can use neither video nor audio, supplemental materials are likely the best thing for an author to provide, again, in links visible to all. For users of legacy UAs that don't support these features, feature-rich alternatives such as plugins can be provided as fallback content for video and audio. Captions and subtitles can be included either directly in the media file, or scripts can manually support external resources using the cue range API. Going forward, we will probably also support dedicated formats that UAs can merge with the video to handle showing external subtitles natively. I don't see a need for an alt= attribute here. What problem would it solve that is not solved by the above solutions? There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. Cheers, Silvia.
Re: [whatwg] Alt attribute for video and audio
On Aug 14, 2009, at 16:06, Silvia Pfeiffer wrote: There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. I believe aria-label addresses this. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Alt attribute for video and audio
On Fri, Aug 14, 2009 at 11:09 PM, Henri Sivonenhsivo...@iki.fi wrote: On Aug 14, 2009, at 16:06, Silvia Pfeiffer wrote: There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. I believe aria-label addresses this. Excellent. Then I haven't seen a good argument to add it. Let's not. Regards, Silvia.
Re: [whatwg] Alt attribute for video and audio
On Fri, Aug 14, 2009 at 3:09 PM, Henri Sivonenhsivo...@iki.fi wrote: On Aug 14, 2009, at 16:06, Silvia Pfeiffer wrote: There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. I believe aria-label addresses this. Yes, I think that covers it. This also covers the most important, but apparently always ignored case: authors who don't have time for accessibility. A significant portion of web authors will not provide subtitles for every published video. Nor will they provide links to a transcript. Even if they care about accessibility, it's just not economically viable to do it. The best you can hope for is a sentence or two explaining what the video does. This also covers other non-text elements: iframe, embed, object. The only thing left is ARIA's integration with HTML. Have you had success with your draft? http://hsivonen.iki.fi/aria-html5/ I see you only had one reply to your first announcement. Will the remaining ARIA attributes be an explicit part of HTML? Will the aria- prefix be removed? Remco
Re: [whatwg] Alt attribute for video and audio
On Wed, 12 Aug 2009 12:52:38 +0200, Remco remc...@gmail.com wrote: On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedtphil...@opera.com wrote: Before suggesting any changes to the source element, make sure you have read http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm Put simply, the handling of source is already quite complex, overloading it with completely different meanings is not a good idea. video won't handle text/html as a source, but if you want different media files for different audiences I suggest experimenting with source media. source media doesn't do anything useful for my case. It can't load textual data. Also, if the resources are unavailable, there will be nothing to see, since all resources are off-page. It also doesn't work for iframe, object, embed or img. Is it really the idea that the only way you're going to have alternative textual content, is to Build It Yourself? You have to abuse details or a hidden div with some Javascript to build a construction that has alternative content in case the video/audio/iframe/object/embed is not available or desirable. If you want it to be semantically accessible, you even have to build another layer on top of that, in the form of ARIA attributes. No, in the long term we want native captions/subtitle support in the browsers. See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html and maybe http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html Nobody will do that. Even the source solution is harder, maybe too hard, to use than the alt= solution. It requires authors to create additional elements or pages to house the alternative content. Since accessibility is often an afterthought, about the most an author will be willing to do, is filling in an alt attribute. What do you suggest a browser do with the alt attribute? The resource selection algorithm never ends until a suitable source is found, so when should the alt text be displayed? By requiring anything at all, browsers can't do things like display a box with a direct download link, suggestion to install a specific codec, etc. If nothing at all is required of user agents for the alt attribute, then I have no opinion (but then I expect no one would use it either). -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Alt attribute for video and audio
On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedtphil...@opera.com wrote: On Wed, 12 Aug 2009 12:52:38 +0200, Remco remc...@gmail.com wrote: On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedtphil...@opera.com wrote: Before suggesting any changes to the source element, make sure you have read http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm Put simply, the handling of source is already quite complex, overloading it with completely different meanings is not a good idea. video won't handle text/html as a source, but if you want different media files for different audiences I suggest experimenting with source media. source media doesn't do anything useful for my case. It can't load textual data. Also, if the resources are unavailable, there will be nothing to see, since all resources are off-page. It also doesn't work for iframe, object, embed or img. Is it really the idea that the only way you're going to have alternative textual content, is to Build It Yourself? You have to abuse details or a hidden div with some Javascript to build a construction that has alternative content in case the video/audio/iframe/object/embed is not available or desirable. If you want it to be semantically accessible, you even have to build another layer on top of that, in the form of ARIA attributes. No, in the long term we want native captions/subtitle support in the browsers. See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html and maybe http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html OK, that's awesome. I mean, really! That is on par with DVD functionality. But that's not exactly my case. It involves subtitling the video. The format has to be learned, and time has to be spent on a video. If a web author has no intention of doing so, but wants to give a short textual alternative and be done with it, he is not able to do that. Nobody will do that. Even the source solution is harder, maybe too hard, to use than the alt= solution. It requires authors to create additional elements or pages to house the alternative content. Since accessibility is often an afterthought, about the most an author will be willing to do, is filling in an alt attribute. What do you suggest a browser do with the alt attribute? The resource selection algorithm never ends until a suitable source is found, so when should the alt text be displayed? By requiring anything at all, browsers can't do things like display a box with a direct download link, suggestion to install a specific codec, etc. If nothing at all is required of user agents for the alt attribute, then I have no opinion (but then I expect no one would use it either). Well, I would suggest that the browser displays the text when no desirable resource is available. In the case of network problems, no resource at all is available. In the case of a textual browser (or a Disable Media button), all videos are undesirable. You can still show a download link or a codec suggestion, but you can display the alt text below it, for the people who don't really care about a video, or people who know the network connection won't be back for some time, or people who can't or won't install the codec. I must admit that I don't understand the media selection algorithm. You say that it never ends. How does that work? The browser keeps looping through the source elements until one becomes desirable and available? How does that give browsers the opportunity to display a download link or a codec suggestion? How should textual browsers handle that? If videos are desirable and available, but text is also desirable, then the alt text could be displayed/spoken/etc when you tab onto it, as Silvia Pfeiffer proposed in a previous email. Remco
Re: [whatwg] Alt attribute for video and audio
On Wed, 12 Aug 2009 14:45:36 +0200, Remco remc...@gmail.com wrote: On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedtphil...@opera.com wrote: On Wed, 12 Aug 2009 12:52:38 +0200, Remco remc...@gmail.com wrote: On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedtphil...@opera.com wrote: Before suggesting any changes to the source element, make sure you have read http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm Put simply, the handling of source is already quite complex, overloading it with completely different meanings is not a good idea. video won't handle text/html as a source, but if you want different media files for different audiences I suggest experimenting with source media. source media doesn't do anything useful for my case. It can't load textual data. Also, if the resources are unavailable, there will be nothing to see, since all resources are off-page. It also doesn't work for iframe, object, embed or img. Is it really the idea that the only way you're going to have alternative textual content, is to Build It Yourself? You have to abuse details or a hidden div with some Javascript to build a construction that has alternative content in case the video/audio/iframe/object/embed is not available or desirable. If you want it to be semantically accessible, you even have to build another layer on top of that, in the form of ARIA attributes. No, in the long term we want native captions/subtitle support in the browsers. See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html and maybe http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html OK, that's awesome. I mean, really! That is on par with DVD functionality. But that's not exactly my case. It involves subtitling the video. The format has to be learned, and time has to be spent on a video. If a web author has no intention of doing so, but wants to give a short textual alternative and be done with it, he is not able to do that. Nobody will do that. Even the source solution is harder, maybe too hard, to use than the alt= solution. It requires authors to create additional elements or pages to house the alternative content. Since accessibility is often an afterthought, about the most an author will be willing to do, is filling in an alt attribute. What do you suggest a browser do with the alt attribute? The resource selection algorithm never ends until a suitable source is found, so when should the alt text be displayed? By requiring anything at all, browsers can't do things like display a box with a direct download link, suggestion to install a specific codec, etc. If nothing at all is required of user agents for the alt attribute, then I have no opinion (but then I expect no one would use it either). Well, I would suggest that the browser displays the text when no desirable resource is available. In the case of network problems, no resource at all is available. In the case of a textual browser (or a Disable Media button), all videos are undesirable. You can still show a download link or a codec suggestion, but you can display the alt text below it, for the people who don't really care about a video, or people who know the network connection won't be back for some time, or people who can't or won't install the codec. I must admit that I don't understand the media selection algorithm. You say that it never ends. How does that work? The browser keeps looping through the source elements until one becomes desirable and available? How does that give browsers the opportunity to display a download link or a codec suggestion? How should textual browsers handle that? The resource selection algorithm loops through the source elements and when it reaches the last one just waits for another source element to be inserted. It doesn't make any distinction between static markup and elements inserted via DOM, so even if you have videosource/video in your markup, it will still wait for another source element to be inserted via DOM. This is for spec simplicity basically, I'm not saying that it's a brilliant use case in itself. The spec says: In addition to the above, the user agent may provide messages to the user (such as buffering, no video loaded, error, or more detailed information) by overlaying text or icons on the video or other areas of the element's playback area, or in another appropriate manner. [end quote] Trying to specify exactly when such extra overlays are appropriate is difficult, because it's really just a guess. Something like when parsing has finished, there are no more source elements and no scripts running that might insert more of them. But that would be wrong sometimes, you have no way of predicting what future scripts might do. If videos are desirable and available, but text is also desirable, then the alt text could be displayed/spoken/etc when you tab onto it, as Silvia Pfeiffer proposed
Re: [whatwg] Alt attribute for video and audio
On Wed, Aug 12, 2009 at 3:52 PM, Philip Jägenstedtphil...@opera.com wrote: The resource selection algorithm loops through the source elements and when it reaches the last one just waits for another source element to be inserted. It doesn't make any distinction between static markup and elements inserted via DOM, so even if you have videosource/video in your markup, it will still wait for another source element to be inserted via DOM. This is for spec simplicity basically, I'm not saying that it's a brilliant use case in itself. The spec says: In addition to the above, the user agent may provide messages to the user (such as buffering, no video loaded, error, or more detailed information) by overlaying text or icons on the video or other areas of the element's playback area, or in another appropriate manner. [end quote] Trying to specify exactly when such extra overlays are appropriate is difficult, because it's really just a guess. Something like when parsing has finished, there are no more source elements and no scripts running that might insert more of them. But that would be wrong sometimes, you have no way of predicting what future scripts might do. OK, so an alt entry in the spec should not mandate its display at a specified situation, but could just suggest it as a possible more detailed information. So the spec would become: In addition to the above, the user agent may provide messages to the user (such as buffering, no video loaded, error, the contents of the alt attribute, or other more detailed information) by overlaying text or icons on the video or other areas of the element's playback area, or in another appropriate manner.[end quote] If videos are desirable and available, but text is also desirable, then the alt text could be displayed/spoken/etc when you tab onto it, as Silvia Pfeiffer proposed in a previous email. I believe that was accomplished with some kind of ARIA attributes, correct me if I'm wrong. I'm no expert on ARIA, but as far as I know it can be done with aria-labelledby. This is pretty complicated though. You have to provide an additional element, style or hide it, and reference it through aria-labelledby. It's pretty DIY. This looks like another longdesc fiasco to me. It has other more realistic uses such as making existing elements (forms, etc) accessible, but I don't see it getting used for arbitrary alternate content. It would be a lot nicer if a web author could just provide an alt text which would show up when the video doesn't load for whatever reason. I don't think it's possible to create an easier tool for web authors to make a video somewhat accessible. Same stuff applies to audio, iframe, object, embed, img. Remco
Re: [whatwg] Alt attribute for video and audio
On Mon, 10 Aug 2009 10:42:36 -0400, Remco remc...@gmail.com wrote: On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. Must at least means that if you can't do it right, here is how to get it only half-wrong (i.e. not good practice, but enough to be useful anyway) title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you ant to provide an alternative, then I suggest that is not a good one. It is a description of the video, rather than a replacement. An alternative is something more like As a ball falls, every second it goes 9.8m/s faster than it was going a second before, because gravity makes it accelerate. In practice, effects such as drag (wind resistance) will affect the actual speed - and the value of 9.8 is specific to the average sea-level of earth - it depends on the mass of the earth and the ball. If you already have this in the preceeding or following text, something like Benjamin's examples, then the job is done and repeating it in alt is redundant and bad practice. To be clear, your example text is better than nothing - and in accesibility that is often as good as it gets :( But there's value to explaining how to do things better - and this particular issue is something that has gathered a *huge* amount of discussion and explanation over the last decade and a half. [snip] To be clear, I think that the existing options for video in HTML5 are better than anything we would gain by adding an alt attribute. The only value I can see in adding one is that some people who are careful enough to use it with images will also use it effectively even if they will do nothing better - but this would require careful large-scale study of authors *as they work* to verify, and I doubt that is going to be done. -- Benjamin Hawkes-Lewis One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. The question now is: why would we need both figure and aria-describedby? Because many designers will not put sufficiently complete text explanations of everything in the ordinary flow of a document. This is actually a valuable accessibility practice - the large number of people who have difficulty reading can often find that their ability to use content is significantly reduced by the presence of large blocks of text. This is something that most usability engineers and communication experts understand instinctively, actually. So we need some way that allows for more than one presentation scenario. Either we ask people to make multiple pages (something that is well-known to suffer from the out of sight out of mind problem, or we provide ways to manage more information in a single page (which also suffers from the problem, but it is believed less so. I don't know how many careful studies have been done of this, if any). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Alt attribute for video and audio
On Tue, Aug 11, 2009 at 8:20 PM, Charles McCathieNevilecha...@opera.com wrote: On 10/08/2009 04:05, Remco wrote: But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you ant to provide an alternative, then I suggest that is not a good one. It is a description of the video, rather than a replacement. An alternative is something more like As a ball falls, every second it goes 9.8m/s faster than it was going a second before, because gravity makes it accelerate. In practice, effects such as drag (wind resistance) will affect the actual speed - and the value of 9.8 is specific to the average sea-level of earth - it depends on the mass of the earth and the ball. Actually, you have provided here not only a description of the video, but also an explanation of why things happen. The video shows a ball falling down and a speedometer increasing with 9.8 m/s per second. Nothing more. My text is simply a replacement for the video. It tells precisely what happens, and nothing more. Of course, you need to see the video (or the replacement text) in context of the Wikipedia article. Without context, neither alternatives make sense. One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. The question now is: why would we need both figure and aria-describedby? Because many designers will not put sufficiently complete text explanations of everything in the ordinary flow of a document. This is actually a valuable accessibility practice - the large number of people who have difficulty reading can often find that their ability to use content is significantly reduced by the presence of large blocks of text. This is something that most usability engineers and communication experts understand instinctively, actually. Ah yes, you're right. So we need some way that allows for more than one presentation scenario. Either we ask people to make multiple pages (something that is well-known to suffer from the out of sight out of mind problem, or we provide ways to manage more information in a single page (which also suffers from the problem, but it is believed less so. I don't know how many careful studies have been done of this, if any). In general I think ARIA needs to be better integrated with HTML. Right now it's just a bunch of additional attributes that don't have a functional purpose for Normal People (TM). It's strictly a foreign extension to HTML that is only really useful for people that care about accessibility (say, 1% of the web author population). Most attributes even have the 'aria' prefix, which tells you that you need to learn some standard for disabled people before you can use this. It would be nice if all ARIA roles could be made into first-class HTML elements. That way, I only have to build my constructs once, and it's accessible implicitly. At the moment, some roles have native HTML counterparts, while others do not. The above has been discussed before, so I'll just add my voice to the choir: the ideas of ARIA desperately need to be integrated into HTML, because as it stands, it will *not* be used. As a small part of integrating the ideas of ARIA into existing HTML 5, I just got an idea for a better solution for replacement content for video and audio: source. The source element is used to provide media elements with multiple sources. What if one of those sources could be an element on the page itself? The text is just another source which could link off-page, or on-page. video source type=video/theora src=primary-content.ogg source type=text/html src=#alternate-content source type=text/html src=alternate-content.html /video Alternative content in source which comes from an element on the same page is an extension to what you already know, and it doesn't require you to know about a special accessibility part of HTML. In addition: currently, source is only used for audio and video, but why not extend it to any external element? iframe src=primary-content.html!-- legacy -- source type=text/html src=primary-content.html source type=text/html src=#alternate-content source type=text/html src=alternate-content.html /iframe objectsource ... source ... /object embedsource ... source ... /embed imgsource ... source ... /img That last one may be problematic,
Re: [whatwg] Alt attribute for video and audio
On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you want to provide an alternative for time-based media (in WCAG 2's phrase), then you want a method that can scale to contain semantic information, such as indicating language changes (lang) or changes of speaker (dialog). Here's how WCAG 2 defines alternative for time-based media: document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing. http://www.w3.org/TR/WCAG20/#alt-time-based-mediadef Here's just three ways you could do this without changing HTML5, assuming the incorporation of WAI-ARIA: 1. figurelegendBall acceleraton.detailsA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./details/legendvideo.../video/figure 2. video title=Ball acceleration aria-describedby=alternative.../videop id=alternativeA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./p 3. video title=Interview with Barack Obama aria-describedby=transcript-link.../videoa href=transcript.html id=transcript-linkTranscript of Interview with Barack Obama/a See also: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (proposal for using aria-describedby in place of longdesc): http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 WCAG 2 Technique G159: Providing an alternative for time-based media for video-only content: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G159 WCAG 2 Technique G58: Placing a link to the alternative for time-based media immediately next to the non-text content http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G58.html Do these features meet your requirements? If not, why not? -- Benjamin Hawkes-Lewis
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you want to provide an alternative for time-based media (in WCAG 2's phrase), then you want a method that can scale to contain semantic information, such as indicating language changes (lang) or changes of speaker (dialog). Here's how WCAG 2 defines alternative for time-based media: document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing. http://www.w3.org/TR/WCAG20/#alt-time-based-mediadef Here's just three ways you could do this without changing HTML5, assuming the incorporation of WAI-ARIA: 1. figurelegendBall acceleraton.detailsA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./details/legendvideo.../video/figure 2. video title=Ball acceleration aria-describedby=alternative.../videop id=alternativeA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./p 3. video title=Interview with Barack Obama aria-describedby=transcript-link.../videoa href=transcript.html id=transcript-linkTranscript of Interview with Barack Obama/a See also: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (proposal for using aria-describedby in place of longdesc): http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 WCAG 2 Technique G159: Providing an alternative for time-based media for video-only content: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G159 WCAG 2 Technique G58: Placing a link to the alternative for time-based media immediately next to the non-text content http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G58.html Do these features meet your requirements? If not, why not? -- Benjamin Hawkes-Lewis A longdesc is not the same as an alt, in that a longdesc is a long description of the content, while an alt is alternative actual content. This distinction may in practice be unnecessary though. And I see that the WAI has redefined alt to mean a short description. Does this mean that the alt attribute and longdesc attribute for images can be combined and deprecated in favor of aria-describedby or a figure/legend combo? It would make the HTML spec more consistent. So instead of this: img title=Tank Man alt=A man stands in front of a column of three tanks. longdesc=page-about-tank-man-photo.html src=tankman.jpg We would get this: img title=Tank Man aria-describedby=tank-desc src=tankman.jpg p id=tank-descA man stands in front of a column of three tanks. a href=page-about-tank-man-photo.htmlMore information/a./p Or this: figure legendTank Man/legend img src=tankman.jpg detailslegendAlternative content/legendA man stands in front of a column of three tanks. a href=page-about-tank-man-photo.htmlMore information/a/details /figure And for an iframe: iframe title=Cool Widget aria-describedby=widget-desc src=http://cool-widget.example.com/user/remco; p id=widget-descAll visiting IP addresses and their browsing history as tracked by Example Inc. are displayed in a list. a href=bigbrother.htmlMore information/a./p Or: figure legendCool Widget/legend iframe src=http://cool-widget.example.com/user/remco; detailslegendDescription/legendAll visiting IP addresses and their browsing history as tracked by Example Inc. are displayed in a list. a href=bigbrother.htmlMore information/a./details /figure One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for
Re: [whatwg] Alt attribute for video and audio
On 10/08/2009 15:42, Remco wrote: On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: Do these features meet your requirements? If not, why not? A longdesc is not the same as an alt, in that a longdesc is a long description of the content, while an alt is alternative actual content. Maybe. Does any W3C recommendation use those precise words to distinguish them? This distinction may in practice be unnecessary though. And I see that the WAI has redefined alt to mean a short description. HTML 4.01 implementations must treat alt as defined in the HTML 4.01 specification. HTML5 implementations would have to treat alt as defined in the HTML5 specification. WAI have not redefined the semantics of W3C markup languages, though they are defining ARIA markup that (it is proposed) will override the native semantics of those other languages in ARIA implementations. In terms of your question about whether video element should allow an alt attribute, I was looking at: * How the editorial draft of HTML5 defines alt. * The WCAG 2.0 Recommendation's conformance requirements for text alternatives for media. I regard discussing how HTML 4.01 defines alt and how WCAG 1.0 or WAI Notes suggest using alt in the context of HTML 4.01/XHTML 1.x as a distraction when trying to answer your question. It seems to me that: 1. Publishers do not need alt on video to meet WCAG 2.0's conformance requirements. 2. Adding alt to video would not meet any other use cases. 3. /If/ I'm wrong and we do need another mechanism to provide a text alternative to meet WCAG 2.0's conformance requirement, it would be better to supply a mechanism that allows markup (e.g. of changes of language and of changes of speaker). Do you agree with these claims? Does this mean that the alt attribute and longdesc attribute for images can be combined and deprecated in favor of aria-describedby or a figure/legend combo? Controversially, longdesc is not conforming markup in the HTML5 editor's draft because of a track record of poor implementations in the web corpus and popular user agents: http://blog.whatwg.org/the-longdesc-lottery This is an open issue for the HTML WG: http://www.w3.org/html/wg/tracker/issues/30 The WAI-CG Task Force on Alternative Text has recommended that longdesc only be obsoleted /if/ aria-describedby is incorporated in HTML5 and aria-describedby allows pointing to long text alternatives that are off of the page (by pointing to a link on the page): http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 I'm suggesting that one could use various /existing/ HTML5 features to provide distinct short descriptions (i.e. titles) and long descriptions (i.e. transcripts) for video and audio elements. alt is problematic for providing text alternatives, since as an attribute it cannot contain markup (e.g. to indicate changes of language). But it is useful for alt to continue to be conforming on elements that currently have an alt attribute since: 1. Many text alternatives do not need markup 2. alt more widely supported by user agents than alternatives like aria-label or aria-labelledby. 3. alt is unambiguously available for all user agents rather than relegated to being provided only to system accessibility APIs. alt on video, on the other hand, is supported by no popular user agents, whereas heading elements, legend, title, aria-label, and aria-labelledby already are supported by some user agents. It would make the HTML spec more consistent. Perhaps. But interoperability may be more important. One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. This touches on some frequently debated points: 1. Are people more likely to provide text alternatives when they are visible? 2. Are such text alternatives likely to be /actual/ text alternatives or will they be more like captions that assume people can see the image? The question now is: why would we need both figure and aria-describedby? figure is an HTML5-specific technology for use by all user agents that indicates a figure. aria-describedby is an HTML-and-XML-general technology that points to a description to be exposed to system accessibility APIs. So they are rather different. -- Benjamin Hawkes-Lewis
Re: [whatwg] Alt attribute for video and audio
At 11:22 +1000 10/08/09, Silvia Pfeiffer wrote: I'd be curious to hear what those problems and provisions are for video and audio. I'm just referring to the rather extensive disciussion of 'alt' for images, and the concern some have with attributes that 'most' people don't see. I do agree that we need to think about both timed-media alternatives and accessibility provisions (captions, audio description of video, etc.) and untimed-media accessibility provisions (alternative text, titles, summaries, links to transcripts etc.). I'm just not sure what the best tools are, etc. Even though I'm a strong supporter of solving the subtitles/captions/i18n/sign language/audio annotation a11y issues of video and audio, I still believe that alt may have a use similar to what it is used for with images. I agree there is a need, I'm just not sure how best to satisfy it. Discussion is good, but let's start with the problems and opportunities, then look at existing structures (such as ARIA) or parallels (such as alt), and see how well we can do. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Alt attribute for video and audio
I have no opinion on the need being adequately covered by other attributes, but… On Sun, Aug 9, 2009 at 11:05 PM, Remcoremc...@gmail.com wrote: For an image this usually works well. An image usually doesn't convey a lot of meaning. It can be replaced by a simple sentence like A young dog plays with a red ball on the grass.. For video, audio, object, iframe, this is a little sparse. Shortening [snip] For some videos a simple textual description is inadequate, just like it is a poor proxy for some still images. Yet for some other videos, it is completely accurate. I have no problem imagining a short video clip which fits your A young dog plays with a red ball on the grass just as accurately as a still image could fit that description. An argument that an attribute is inadequate to cover *all* cases shouldn't be used as a reason to exclude something which is useful in many case.
[whatwg] Alt attribute for video and audio
Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Remco
Re: [whatwg] Alt attribute for video and audio
At 1:12 +0200 10/08/09, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Your search was too quick...we are discussing accessibility provisions for video and audio in general. Have a look under that. I think alt has been shown to have problems as well as provisions...perhaps we can find a better way? -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Alt attribute for video and audio
Am Montag, den 10.08.2009, 01:12 +0200 schrieb Remco: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Hmm … subtitles have not been discussed before ? I don't think so. Or what else do you think could enhance accessability ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Alt attribute for video and audio
On 10/08/2009 00:12, Remco wrote: Shouldn'tvideos andaudios (and maybeobjects too?) also have an alt attribute? Bearing in mind: http://www.w3.org/TR/WCAG20/#text-equiv and http://www.w3.org/TR/WCAG20/#media-equiv What function would alt on video serve? -- Benjamin Hawkes-Lewis
Re: [whatwg] Alt attribute for video and audio
My search was indeed too quick. I stand corrected. Captions/subtitles seem like a very good idea for accessibility, but in addition to that I think that an alt attribute would still be appropriate for browsers that can't display the media at all. The alt is a replacement for an external element that cannot be displayed at all for whatever reason. It replaces the element. That's why I would suggest alt attributes for objects, embeds, frames, etc. too. Remco
Re: [whatwg] Alt attribute for video and audio
On Sun, Aug 9, 2009 at 6:50 PM, Remcoremc...@gmail.com wrote: My search was indeed too quick. I stand corrected. Captions/subtitles seem like a very good idea for accessibility, but in addition to that I think that an alt attribute would still be appropriate for browsers that can't display the media at all. The alt is a replacement for an external element that cannot be displayed at all for whatever reason. It replaces the element. That's why I would suggest alt attributes for objects, embeds, frames, etc. too. If a particular UA does not support the video element at all, it should display the fallback content inside the element. ~TJ
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 2:15 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: On Sun, Aug 9, 2009 at 6:50 PM, Remcoremc...@gmail.com wrote: My search was indeed too quick. I stand corrected. Captions/subtitles seem like a very good idea for accessibility, but in addition to that I think that an alt attribute would still be appropriate for browsers that can't display the media at all. The alt is a replacement for an external element that cannot be displayed at all for whatever reason. It replaces the element. That's why I would suggest alt attributes for objects, embeds, frames, etc. too. If a particular UA does not support the video element at all, it should display the fallback content inside the element. ~TJ But that fallback content will not be rendered when the video isn't available. The same is true for audio. Object, embed and iframe don't have any fallback at all. If these external resources are unavailable, or if administrative policies prevent loading of external resources, there is no alternative content. It will just be an empty square on the page (or skipped by a screenreader / ignored by a textual browser, etc.). I would argue that alternative content is just as useful for any external content as it is for the specific external content that is images. Remco
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 9:22 AM, David Singersin...@apple.com wrote: At 1:12 +0200 10/08/09, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. Your search was too quick...we are discussing accessibility provisions for video and audio in general. Have a look under that. I think alt has been shown to have problems as well as provisions...perhaps we can find a better way? Dave, I'd be curious to hear what those problems and provisions are for video and audio. Even though I'm a strong supporter of solving the subtitles/captions/i18n/sign language/audio annotation a11y issues of video and audio, I still believe that alt may have a use similar to what it is used for with images. E.g. when you tab onto a video element, the alt tag could give a very brief summary as to what the video is about, e.g. Elephant Dreams video. It would be much shorter and not time-aligned. But I am curious in people's opinions about this. Cheers, Silvia.
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 4:13 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 02:22, Silvia Pfeiffer wrote: E.g. when you tab onto avideo element, the alt tag could give a very brief summary as to what the video is about, e.g. Elephant Dreams video. Don't the following already do that: 1. video title=Elephant Dreams video ... 2. h3 id=elephantsElephant Dreams video/h3video aria-labelledby=elephants ... 3. video aria-label=Elephant Dreams video ... What would alt add here? -- Benjamin Hawkes-Lewis A title is a short description, and could be the movie title in the case of a video element. An alt is a textual alternative for the content. It conveys the same meaning as the img, audio, video, iframe, ... element. It doesn't describe the content: it *is* the content. For an image this usually works well. An image usually doesn't convey a lot of meaning. It can be replaced by a simple sentence like A young dog plays with a red ball on the grass.. For video, audio, object, iframe, this is a little sparse. Shortening Elephants Dream's content to An old man and a young boy walk through a surrealistic world and have a conversation. doesn't tell you a lot about the content. But it is very helpful if the content is not available. It is even more helpful if it isn't as short as the previous alt-text for Elephants Dream. If it gives more details about what you see and hear in the video, you get information that for example a plot description doesn't provide. But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. Remco
