- From: David Poehlman <poehlman@clark.net>
- Date: Sun, 23 Jul 2000 08:33:28 -0400
- To: Al Gilman <asgilman@iamdigex.net>
- CC: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
al, I think you have captured the escence of our intent. in ie, if you uncheck play sounds, no sounds are played automatically but here again, we don't have the opportunity to know that a sound exists if it is a background sound and thus play it as a stand alone sound file. the last thing I want is for an unexpected sound to come blaring! out of my speakers in an inappropriate place and or time not to mention the load increase. take for example one I created at: http://www.clark.net/pub/etowski/ it is large and plays only once but takes a long time at 33.6 to load and in ie for some reason it is jerky on my win.95 box so I'd rather not hear it. it is a wav. midis don't pose this issue for me but I am sure they might for some. Thanks. Al Gilman wrote: <snipped to remarks: > AG:: > > I see "quick and truly dirty" ways to do this and "clean and truly too slow > for UAAG" ways. So I want to know what is the question that we _have_ to > answer to release the UAAG as a Recommendation. The subject line says > "issue 297." > > <quote issue> > > Issue 5) Style v. content and background sounds. > > [Note: I believe Eric has already raised this point a number of > times.] > Question: Some content is only meant to decorate. This includes > simple > graphics, colors, animations, and sounds (namely background sounds). > We require the UA to allow the user to control the volume, speed, and > other aspects of animations and sounds. But it seems like this is > overkill > for visual or sound content that is only meant for decoration. > > The author is required by WCAG 1.0 to include text equivalents > for every non-text. It may be a bug in WCAG 1.0, but I don't think > this > should be required for non-text content that is only used for > decoration. > We don't require a text equivalent for the fact that the background > color > of a page is pale yellow. Should we require a text equivalent for > a background sound that adds to the browsing experience but is only > > *background sound*, i.e., decoration? > > <end quote> > > My opinion on the particular question at hand is that I would not try to > give User Agents an exception in this case because it does put information > the user could beneficially use out of reach, and it doesn't really save > the User Agent much. > > The reduced requirement that I am contemplating is that if a sound is > invoked from a BGSOUND attribute or an EMBED element that the only > requirement would be to allow the user to permit or forbid the play of the > sound. > > The reason this is a bad idea is that it is reasonable and useful for the > user to inspect the sound, that is play the sound by itself, even in > situations where by reason of contention over the audio output channel the > user cannot tolerate having the sound playing in the background as part of > browsing the other content of the page. > > Compare the "image links" function in Lynx where all IMG references are > turned into links so that the image can be inspected, i.e. displayed > separately from the page context. > > The reason I say the exception doesn't save the User Agent builder much of > anything is that the difficulty of providing controls over the play of the > sound is associated with the type, not the role, of the sound. What > matters in this regard is whether the sound is MIDI, WAV, or Real, not > whether it is elevator music in the background or the voice announcing that > you have won the million dollars. > > The user should have the capability to play a) the whole ensemble, b) just > the sound, or c) the whole ensemble without the sounds in the ensemble. > This last would be required because the audio channel has been reserved for > the reading of the text. > > Then, in the case of playing just the sound, all the controls that the > player exposes for this type should be available, and we would like them to > meet our list. No matter that the user is inspecting a decoration on the > original page. That is what they are focusing on, and the usual play > controls are of interest in this scenario. > > One key thing to realize about a background sound is that the > syncronization of a background sound with the rest of the document is very > loose. They are not syncronized except that the sound is germane inside > some document region and not germane outside that region. This is as far > as the association gets. There is no relationship that matters between > where you are in the sound and where you are in the rest of the document. > So aside from the ability to include, exclude, or inspect the sound, there > is no more fine-grained syncronized access to the whole thing that needs to > be required. > > I agree that the "inspect function" may be a new function for the browser > presenting pages with background sounds, but it is the same old requirement > that we need all over the place in multimedia. This looks like one of > those places where we should screw up our courage and say "Yes, if you are > going to use multimedia effects in web pages, you should live by multimedia > rules." Enabling the user to play the pieces in isolation is one of those > generic rules. > > So, to return to the smaller question, I don't think we need to go through > HTML and designate which sound roles are substantive and which can be > relegated to "just decoration" because in fact the language does not > enforce this to a sufficient degree. What goes in the sounds covers the > full range of decorative to substantive regardless of how invoked. > Besides, I don't think we need to answer _how_ to tell which sound roles > are considered to be decorative, because I don't myself believe we should > make the exception in the first place. Just because people need to > suppress the background as background doesn't mean they don't need to be > able to hear the sound (separately). > > Al -- Hands-On Technolog(eye)s ftp://poehlman.clark.net http://poehlman.clark.net mailto:poehlman@clark.net voice 301-949-7599 end sig.
Received on Sunday, 23 July 2000 08:32:21 UTC