Re: [Fwd: Request for review of accessibility note]

        Reply to:   RE>>[Fwd: Request for review of accessibility note] 

I'm replying to comments made by both Marja and Lloyd.  My comments preceded by GF:

Marja wrote:
I thought we could give a class name to audio descriptions and users could
use cascading mechanism to turn the audio descriptions on in their personal
style sheets. Of course we really need this mechanism for the player.

And Lloyd replied:
Do you mean that this assumes unspecified functionality of CSS?

GF:
Players definitely should have a mechanism for turning on and off descriptions.  While it might be possible (and for some users, preferable) for a user to create a style sheet to accomplish this, I think we should make it as easy as possible for users to customize the access features.  CSS is one way, but perhaps not the easiest.  Selecting a preference from a menu or dialog box is.  This is where something like "system-audio-descriptions=on/off" would come in handy.

Lloyd wrote:
A similar mechanism to this was used in my lab's multimedia authoring
research prototype, which was later adapted for SMIL.  In the pre-SMIL
days, audio tracks were assigned particular "channels".  There could
be and "audio description channel" and a "German dubbing" channel, and
so forth.  In the body temporal hierarchy, all of these audio clips
would be scheduled for "playing" in all presentations -- that is, they
would be scheduled for being sent to their channels.  However, for
each presentation, different individual channels could be turned on
and off.  This was one technique for adapting to individual users.
Would a similar technique be useful in a future version of SMIL?

GF:
FYI, this is how QuickTime delivers information today:  all tracks of audio, video and text are played at once, and the user can toggle on and off the appropriate tracks.  

Lloyd wrote:
Perhaps the note could discuss having such integrated HTML with a CSS
class such as "captioning" or "subtitle".  Or should both be used?
Are there differences in how captions and subtitles get processed and
played?  The note could also discuss how SMIL presentations should
account for using CSS style sheets for overriding such integrated
subtitles.

GF:
Captions usually contain more information than subtitles, like sound effects and speaker identification.  In some cases, the timing differences between one movie's captions and subtitles can be significant.  Having separate classes for caption and subtitles would therefore, I think, be a great idea.  (An aside for another forum, but still worthwhile here:  SMIL 1.0 uses "system-overdub-or-caption" when what is really intended, I think, is "system-overdub-or-subtitle".  Perhaps this is something that could be addressed in SMIL 2.0?)

Lloyd wrote:
The use of transparency raises some possibilities and issues that may
be worth discussing... A related issue is the use of a "partially transparent" (I don't know
the conventional term -- maybe "translucent") background, which still
leaves the overlap of the visual display perceivable (though not as
well), but also makes the text easier to read.  This is used in some
subtitles.  I have seen a mechanism for providing this "partial
transparency" in images in general, but am not aware of how widely
implemented and used it is.  I believe the mechanism for this involves
pixel-by-pixel arithmetic which the pixel darkness is lowered by some
amount or percentage.

GF:
NCAM experimented recently with QuickTime captions using a translucent background; depending on the case, the captions (or subtitles) were, in fact, much easier to read.  QuickTime has a pretty simple mechanism for the author to adjust the percentage of translucency; I think this would be very useful in SMIL, especially if the user can adjust the translucency, too.  (By the way, some broadcast closed-caption decoders already have a translucency feature.)

Something else helps make captions/subtitles easier to read is applying a 1-pixel outline around each character.  Again, you can do this in QuickTime.  This would be useful in SMIL, too.

Geoff Freed
WGBH/NCAM

--------------------------------------
Date: 8/12/99 7:23 AM
To: Geoff Freed
From: Lloyd Rutledge

On Wed, Aug 11 1999 Marja-Riitta Koivunen wrote:

> I thought we could give a class name to audio descriptions and users could
> use cascading mechanism to turn the audio descriptions on in their personal
> style sheets. Of course we really need this mechanism for the player.

Do you mean that this assumes unspecified functionality of CSS?

A similar mechanism to this was used in my lab's multimedia authoring
research prototype, which was later adapted for SMIL.  In the pre-SMIL
days, audio tracks were assigned particular "channels".  There could
be and "audio description channel" and a "German dubbing" channel, and
so forth.  In the body temporal hierarchy, all of these audio clips
would be scheduled for "playing" in all presentations -- that is, they
would be scheduled for being sent to their channels.  However, for
each presentation, different individual channels could be turned on
and off.  This was one technique for adapting to individual users.
Would a similar technique be useful in a future version of SMIL?

> Do you mean that CSS should be used with the textual media object elements
> containing HTML or XML?

CSS works on both HTML and XML to make tailored presentations of text.
CSS can be applied to individual HTML and XML media items integrated
into a SMIL presentation as well as to the SMIL presentation itself.
The use of CSS on text integrated into multimedia presentations has
potential for enhancing accessibility.  This use also raises some
issues.  Some of these techniques and issues may be appropriate for
the Accessibility in SMIL document.

The use of CSS on HTML or XML applies well to closed captions or
subtitles (from here on the word "subtitles" applies to both).  Text
that acts as subtitles for audio can be displayed in a number of ways.
Certain users may prefer or need certain types of display of subtitled
text.  For example, if color is used to distinguish between various
types of text, then color blind users will want to have this technique
replaced with another for their presentations.  Also, users with lower
visual acuity will want their text shown in larger fonts.  They may
also want to turn off transparent backgrounds for such text, which is
described below.

Perhaps the note could discuss having such integrated HTML with a CSS
class such as "captioning" or "subtitle".  Or should both be used?
Are there differences in how captions and subtitles get processed and
played?  The note could also discuss how SMIL presentations should
account for using CSS style sheets for overriding such integrated
subtitles.

Another issue is what to do if subtitles get resized to become larger
and as a result exceed their assigned regions.  SMIL has a "scale to
fit" option, but this does not apply to HTML in the current browsers.
However, HTML can still be "cropped" or "scrolled" by SMIL code.  In
your recommendations to authors, are there guidelines in how to
prevent or, when unavoidable, handle subtitles that are larger than
their regions?  Is this issue handled in current practice with
subtitles?  Are there ways to use CSS to specify how to handle these
situations within SMIL?  Is scrolling an option?  Or should scrolling
be avoided with some alternative, such as alternative larger regions
with more room for text but less for the rest of the display?

The use of transparency raises some possibilities and issues that may
be worth discussing.  Authors sometimes want the visual display of
such text to be integrated with the visual display of the other visual
media through the use of transparency.  Subtitles are often shown
within a video display along the bottom, with the video being visible
behind the letters.  This is often done for TV and motion pictures, in
which the original visual display space needs to be used, but you do
not want the use of subtitle to block as little of the visual display
as possible.  In order to have this affect with SMIL and HTML:

 1) The HTML would have to be displayed in a region on top of the video

 2) The HTML would have to be specified with a transparent background

 3) SMIL browsers would have to have the convention that transparency
    in displays of regions with lower z-index's lets through the display of
    overlapped regions of higher z-index's.

(1) can be encoded in SMIL.  (2) can be satisfied by applying CSS-2 to
the HTML making up subtitled text.  (3) is at least partly satisfied
in that region background colors inherit CSS-2 background colors,
including "transparent".  However, which among the following apply to
SMIL's use of transparent background?

 3a) The region does not block overlapping regions of higher z-index
     when nothing is displayed in it?

 3b) Right and bottom margins between visual displays and the
     regions borders also do not do this blocking?

 3c) Areas of the visual display that are transparent (such as PNG and
     HTML also do not do this blocking?

None of these three are explicitly stated in the SMIL spec (please
correct me if this is wrong), but at least (3a) and (3b) are generally
assumed and implemented, and I think (3c) is as well.  (Is anyone
familiar enough to know how this is handled with CSS, and would thus,
by inheritance through SMIL's CSS-based regions, be handled in SMIL?)
These three are important for transparent subtitle backgrounds.  This
use is an example of the use of CSS with text in SMIL presentations
that enhances accessibility.

A related issue is the use of a "partially transparent" (I don't know
the conventional term -- maybe "translucent") background, which still
leaves the overlap of the visual display perceivable (though not as
well), but also makes the text easier to read.  This is used in some
subtitles.  I have seen a mechanism for providing this "partial
transparency" in images in general, but am not aware of how widely
implemented and used it is.  I believe the mechanism for this involves
pixel-by-pixel arithmetic which the pixel darkness is lowered by some
amount or percentage.

This "partial transparency" is not accounted for in CSS-2 background
color settings.  It could possibly be approximated by using a
background image of PNG (or GIF) meshes with alternating white (or any
solid color) and transparent pixels -- with which more transparent
pixels would provide more transparency.  I am not aware of this
technique being used.  One problem with this technique is that the
effect is of lower quality than the previously mentioned technique.
Another consideration is that images of transparent pixel meshes can
lose effectiveness if scaled.

In any event, "partial transparency", for the most part, cannot be
done with SMIL 1.0, and thus is not appropriate for inclusion in the
current note draft.  However, it may be a feature that is worth
addressing in future version of web standards.  Should CSS have as a
background color a color with a percentage of transparency?  Should
PNG have translucency as well as transparency?

-Lloyd

--
Lloyd Rutledge                              vox: +31 20 592 41 27
CWI (Centrum voor Wiskunde en Informatica)  fax: +31 20 592 41 99
PO Box 94079                                net: Lloyd.Rutledge@cwi.nl
NL-1090 GB Amsterdam, The Netherlands       Web: http://www.cwi.nl/~lloyd


------------------ RFC822 Header Follows ------------------
Received: by wgbh.org with ADMIN;12 Aug 1999 07:20:52 +0100
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id HAA28313;
	Thu, 12 Aug 1999 07:18:01 -0400 (EDT)
Resent-Date: Thu, 12 Aug 1999 07:18:01 -0400 (EDT)
Resent-Message-Id: <199908121118.HAA28313@www19.w3.org>
Message-Id: <UTC199908121117.NAA07043.lloyd@klipper.cwi.nl>
To: symm@w3.org, ij@w3.org, dd@w3.org, wai-liaison@w3.org, w3c-wai-eo@w3.org
cc: Marja-Riitta Koivunen <marja@w3.org>, Philipp Hoschka <ph@w3.org>
In-reply-to: Your message of "Wed, 11 Aug 1999 17:51:22 MET DST."
             <3.0.5.32.19990811175122.00a34c10@localhost> 
Date: Thu, 12 Aug 1999 13:17:44 +0200
From: Lloyd Rutledge <Lloyd.Rutledge@cwi.nl>
Subject: Re: [Fwd: Request for review of accessibility note] 
Resent-From: w3c-wai-eo@w3.org
X-Mailing-List: <w3c-wai-eo@w3.org> archive/latest/946
X-Loop: w3c-wai-eo@w3.org
Sender: w3c-wai-eo-request@w3.org
Resent-Sender: w3c-wai-eo-request@w3.org
Precedence: list

Received on Thursday, 12 August 1999 09:55:30 UTC