- From: Benjamin West <bewest@gmail.com>
- Date: Sat, 17 Mar 2007 20:12:47 -0800
On 3/5/07, H?kon Wium Lie <howcome at opera.com> wrote: > Also sprach Elliotte Harold: > > > If we add a video element, should we for the same reasons add an audio > > element? > > Yes. > I agree. I was thinking about what Christoph P?per said, in <video> element proposal: On 3/17/07, Christoph P?per <christoph.paeper at crissov.de> wrote: > |video| should be used to embed audio files and streams, too, because in > practice it is a superset. * Should users be given a control to manipulate embedded audio? * If using Audio(), who's responsibility is it to provide that control/user interface? UA? Authors? I don't have any research, but I would suspect that in practice, it would be beneficial to encourage the presentation of a UI for audio. Just because the medium isn't visual doesn't mean users don't need to see a control. Typically, when web pages embed audio, there is a control somewhere on the page for playing, stopping, pausing, rewinding, and the features increase from there. If end users can't shut off the music embedded in a web page, I would consider that a problem. So, since it's important to actually show a visible UI, and since the location of that control in the document is important, there should probably be an <audio> element, or allow <video> to also play audio. Are there any usability or accessibility guidelines we're following that would mandate providing some level of playback/volume controls over multimedia? Does anyone have research on how many instances of embedded media on the web offer some sort of visible control? I don't think any of this is an argument for introducing a <media> element, nor for extending <object>. If there were a newly named element to support both video and audio, I would not expect it to be called media, but perhaps something like "playback", because the controls and authoring intent appear pretty similar to me. -Ben West
Received on Saturday, 17 March 2007 21:12:47 UTC