- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sat, 22 Jul 2000 16:39:57 -0400
- To: Ian Jacobs <ij@w3.org>
- Cc: w3c-wai-ua@w3.org
At 10:59 PM 2000-07-21 -0400, Ian Jacobs wrote: > >> So at least in HTML it is possible to talk about markup with >> presentational semantics and markup with structural semantics, but it is >> not possible to partition the set of element types into two groups which >> are purely one and purely the other. > >Is that true for all elements (e.g., FONT) or just some? If possible >for some elements, then I suggest we try to identify them. > 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
Received on Saturday, 22 July 2000 16:34:41 UTC