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

Al Gilman wrote:
> 
> 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.

[snipped some intro text from AG]
My comments preceded by IJ:

> 
> 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.

IJ: 
My understanding has been that information conveyed through style sheets
(or their markup equivalents) is intended for a particular rendering
only and is "disposable" with respect to other renderings. Of course,
we require that the raw style sheet be available to the user (as part
of all content). Refer to our discussion about the "W3C Working Draft"
background image and lack of alt text from 1999.
(Question from Ian [1], Responses from Al [2], [3], [4])

 [1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0202.html
 [2] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0203.html
 [3] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0204.html
 [4] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0205.html 

We ask user agents to allow users to turn off background images because 
they can get in the way. However, we don't require more control 
than that (e.g., the ability to inspect the image as Lynx provides)
since
background images are disposable and don't require additional control.
Of course, it's possible to abuse style sheets; the author could insert
the entire document with the 'content' property. But this is an
authoring
problem, and I don't know whether we should make additional requirements
on user agents based on bad authoring practices.

> 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.

IJ: 
That is the part that I don't agree with. Do users need to rewind
or slow down sounds that are used purely for decoration? 

Are authors required to provide a text transcript for background sounds 
that have words? We have said that authors are not required to provide
alt text for list bullets because they are graphical decoration for
structure encoded in markup (refer to discussion on the WCAG 
list from Nir in 1999 [5]). I think that we should require user
agents to provide adequate control over content rendering, but I think
we don't need to require maximum control over content whose role
is only decorative.

[5] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0077.html

On a related note: Should we require user agents to allow users to
rewind and slow down beeps or other short sounds (even "You've got
mail")?
Those sounds may be part of the native user interface or part of
content.
These sounds have a function: convey a message about an event. We
require
that these messages be made available as text in the user interface
(checkpoint 1.5). Are we also requiring stop, start, pause, rewind,
advance, and slow down of this audio? If not, why not? In this case,
the information is not purely decorative. 

The fact that some piece of audio content has a text equivalent doesn't
mean that the user agent shouldn't provide control over the audio. Thus,
I'm not arguing that as soon as an auditory track has an associated 
text transcript, additional control is not required. But I don't think
users need to be able to rewind beeps. 

Refer to comments from Eric Hansen about "short sounds" not being
part of audio presentations ([6], [7]).

 [6] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0752.html
 [7] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0374.html

> 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.

IJ: Is that an authoring problem? Or just because one can't draw
the line. If it's an authoring problem (i.e., encoding non-decorative
information in style) then I don't see why the user agent developers
should have to implement more control. 

> 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).

What about the ability to inspect background images separately? That
is not currently required by the UA Guidelines. Except that checkpoint
2.1 requires access to all content. We do not have a requirement that
the user be able to navigate to and inspect all referenced content.

Thanks for the comments Al!

  _Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Sunday, 23 July 2000 12:47:14 UTC