Re: Comments on presentation/structure related to issue 297.

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