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

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

Marja wrote:
I think we really want to have system-overdub and system-subtitle
separately (and it would be also nice have some metadata to separate the
captions, subtitles, audio descriptions and overdubs because the test
attributes can be used in other ways too). Then the user interface in the
player could give the either-or alternatives if necessary.

GF:
This is a good idea.  Making them all yes/no rather than some yes/no and some either/or will help avoid confusion. 

Geoff Freed
WGBH/NCAM


--------------------------------------
Date: 8/12/99 10:50 AM
To: Geoff Freed
From: Marja-Riitta Koivunen
At 09:57 AM 8/12/99 +0000, Geoff Freed wrote:
>        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:

... left out some things that GF already answered

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

I think we really want to have system-overdub and system-subtitle
separately (and it would be also nice have some metadata to separate the
captions, subtitles, audio descriptions and overdubs because the test
attributes can be used in other ways too). Then the user interface in the
player could give the either-or alternatives if necessary.

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

Translucency seems to be a good feature, in addition, sometimes e.g. with a
big screen the captions or subtitles can also be under the picture.

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


------------------ RFC822 Header Follows ------------------
Received: by wgbh.org with ADMIN;12 Aug 1999 10:47:20 +0100
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id KAA02143;
	Thu, 12 Aug 1999 10:32:55 -0400 (EDT)
Resent-Date: Thu, 12 Aug 1999 10:32:55 -0400 (EDT)
Resent-Message-Id: <199908121432.KAA02143@www19.w3.org>
Message-Id: <3.0.5.32.19990812103030.00993ea0@localhost>
X-Sender: marja@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 12 Aug 1999 10:30:30 -0400
To: "Geoff Freed" <Geoff_Freed@wgbh.org>, dd@w3.org, ij@w3.org,
        "Lloyd Rutledge" <Lloyd.Rutledge@cwi.nl>, symm@w3.org,
        w3c-wai-eo@w3.org, wai-liaison@w3.org
From: Marja-Riitta Koivunen <marja@w3.org>
Cc: "Philipp Hoschka" <ph@w3.org>
In-Reply-To: <n1277670622.83772@wgbh.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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/948
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 11:03:26 UTC