W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 1999

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

From: Marja-Riitta Koivunen <marja@w3.org>
Date: Wed, 11 Aug 1999 17:51:22 -0400
Message-Id: <>
To: Philipp Hoschka <ph@w3.org>, ij@w3.org, symm@w3.org, dd@w3.org, wai-liaison@w3.org, w3c-wai-eo@w3.org
At 08:26 PM 8/9/99 +0200, Philipp Hoschka wrote:
> Return-Path: <symm-request@w3.org>
>Received: from sophia.inria.fr by www45.inria.fr (8.8.8/8.8.5) with ESMTP
id UAA01631 for <hoschka@www45.inria.fr>; Mon, 9 Aug 1999 20:02:23 +0200
>Received: from www10.w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id
UAA02313; Mon, 9 Aug 1999 20:01:26 +0200 (MET DST)
>Received: from www19.w3.org (www19.w3.org [])
>	by www10.w3.org (8.9.1/8.9.1) with ESMTP id OAA13931;
>	Mon, 9 Aug 1999 14:01:19 -0400 (EDT)
>Received: (from daemon@localhost)
>	by www19.w3.org (8.9.0/8.9.0) id OAA11807;
>	Mon, 9 Aug 1999 14:01:13 -0400 (EDT)
>Resent-Date: Mon, 9 Aug 1999 14:01:13 -0400 (EDT)
>Resent-Message-Id: <199908091801.OAA11807@www19.w3.org>
>Message-Id: <UTC199908091800.UAA168722.lloyd@klipper.cwi.nl>
>To: symm@w3.org
>cc: Philipp Hoschka <ph@w3.org>, Lynda.Hardman@cwi.nl
>In-reply-to: Your message of "Wed, 28 Jul 1999 10:24:09 MET DST."
>             <379EBE29.E113BCB9@w3.org> 
>Date: Mon, 09 Aug 1999 20:00:31 +0200
>From: Lloyd Rutledge <Lloyd.Rutledge@cwi.nl>
>Subject: Re: Request for review of accessibility note 
>Resent-From: symm@w3.org
>X-Mailing-List: <symm@w3.org> archive/latest/299
>X-Loop: symm@w3.org
>Sender: symm-request@w3.org
>Resent-Sender: symm-request@w3.org
>Precedence: list
>X-Mozilla-Status2: 00000000
>This post is a response to the draft for "Accessibility Features of
>The SMIL Boston draft [2] is now out, and it has many new features
>that apply to accessibility and would be worth discussing in this
>document.  Geoff Freed has posted to www-smil some comments regarding
>how SMIL Boston to address accessibility [3].

It has been decided that this only talks about SMIL 1. The future
discussions will be in the dependency reports. I think there will be
another Note for SMIL Boston.

While continuing to develope the next SMIL version I think it would be good
to gather some use scenarios of the new features. That would help to see
what the needs are and how well the features response to the needs.

>Can WAI offer any suggestions for player implementors on how to best
>handle opening new windows for users that don't favor them?

There has been some discussion of this in the WAI groups. At least the user
should be informed of the new windows and be able to prevent opening them
(i.e. use the same window all the time). To get a comprehensive answer I
think it would be good to send this question to UA and PF groups.

>The navigation bar suggested in 4.3 can be more easily implemented in
>SMIL Boston with the excl construct.  It could also address the issues
>in 4.1 and 4.2.  In all cases, users who want to see all of the links
>in the document in one, easy to perceive, all at once format, can have
>a "link bar" providing access to all link endpoints.  This could
>be turned on and off as a bar during the whole presentation.

Sounds great! I need to look that more carefully.

>[Section 3.1, para 1, 2nd to last sentence]
>> Style sheets may not be supported by all SMIL browsers, however.
>The SMIL accessibility document discusses the use of CSS in several
>places.  The use of CSS with SMIL is indeed important for SMIL's
>accessibility.  However, it should be noted that currently there is no
>SMIL browser that supports any use of CSS with SMIL, and this support
>has not been announced as forthcoming for any browser.


>The formatting of text is important for the use of closed captions and
>subtitles.  SMIL 1.0 may not provide all that is need for integrating
>formatted text into SMIL presentations.  One problem is that different
>browsers do not display formatted or unformatted text consistently.
>Another is that closed captions and subtitles frequently rely on
>transparency and ghosting.  This function is not currently implemented
>on SMIL browsers.  It is also unclear whether or not this function is
>encodable with formatted or unformatted text integrated into SMIL.
>It might be worthwhile to remark on the use of CSS to all formatted
>HTML (and XML?) text in a SMIL presentation on SMIL browsers.

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

>> 2.2.2 Auditory Descriptions
>> Note. In CSS, authors may turn off auditory descriptions
>> using 'display : none', but it is not clear what value of 'display'
>> would turn them back on.
>It is also unclear how CSS used in SMIL could turn on and off auditory
>descriptions that are integrated in SMIL code.  The integration of the
>audio would have to happen in the CSS code itself.

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.

>> In SMIL 1.0, auditory descriptions may be included in a presentation
>> with the audio element. However, SMIL 1.0 does not provide a mechanism
>> that allows users to turn on or off player support for auditory
>> descriptions. 
>I've posted a suggestion, originally made by Geoff Freed, about the
>addition of a "system-audio-desc" test attribute [6].  Geoff's recent
>www-smil post applies here as well [3].  Perhaps we could include in
>the draft a discussion of this potential SMIL extension.  Perhaps we
>could go further by suggesting the addition of a WAI namespace
>extension for the attribute (assuming people are willing to implement
>it).  There are people who want to start working with this attribute
>right away.

As I said earlier the Note is just on SMIL 1.0 and I understood from the
SYMM group that there is no chance to make changes to that. I don't believe
it is officially possible to do something faster than waiting for next SMIL
recommendation, but maybe I'm wrong. 

>A problem with many of the examples is that timing information for the
>presentation has been placed in RealNetworks formats instead of in the
>SMIL code.  SMIL is capable of encoding the timing information that
>appears to have been put in RealNetworks formats in the examples.  If
>there is a reason that the timing was encoded in RealNetworks formats
>instead of in SMIL, this should be stated.  Otherwise, all of the
>timing information should be in SMIL.

We just wanted to point out some things and therefore did not include all
the timing to the examples. The file extensions came mainly from the
examples used in SMIL 1.0 document. I hope to get an example caption file
with SMIL time attributes to the document. So there would be at least one
example of that.

>The primary advantage of encoding the timing in SMIL is that you can
>use implicit timing and adaptive timing instead of only absolute
>A disadvantage of relying on RealNetworks formats for timing is that
>browsers would have to be able to play the formats and the timing
>information in them.  However, G2 (of course) and GRiNS do this.  I
>think SOJA does not, no do any of the others that I am aware of.
>Another disadvantage of relying on RealNetworks formats for timing is
>that the timing is tied to the playing of one media item rather than
>the progression of the whole presentation.  This is not a large
>problem for "hard synchronization" players, because all the media
>would automatically stay in synch with each other.  However, for "soft
>synchronization" players, if the playing of one media item slows down,
>the others will not necessarily slow down in synchrony.  By encoding
>the timing in SMIL, however, this keeping pace between different media
>objects can be done for both hard and soft synchronization players.
>One advantage of using Real Text with timing for subtitles and closed
>captioning could be that it enables all of the displayed text to be
>put in single text file instead of a separate text file for each piece
>of displayed text.  However, there are ways within SMIL to not require
>a separate text file for each individual text caption or subtitle.
>One way to limit the number of external text files needed and still
>have the timing information in the SMIL code is to use data URL scheme
>for the text [4,5].  This way, all of the text used in in the SMIL
>file itself, and no external text files at all are needed.  For
>example, a piece of text that was originally included as
>  <text src="HelloJoe.txt">
>could instead be included through URI data schemes with
>  <text src="data:,Hello, Joe.">
>URI data schemes can also handle formatted text by declaring a type
>of HTML for the included data, for example, the above text can be
>formatted as italicized with
>  <text src="data:text/html,<EM>Hello, Joe.">
>The GRiNS browser can handle URL data schemes that are untyped, plain
>text.  I don't think any SMIL browser currently displays formatted
>text as an URL data scheme.  Netscape (used as an HTML browser, of
>course) does handle the display of typed, formatted text included with
>URL data schemes.
>{@@@ Can anyone comment on the use of "|" instead of "#" to include
>different portions of the same, single external text file?}
>Given this, below is a recoding of the final example in section 2.
>The first 3 seconds of the video have one caption.  The second 3
>seconds have another caption.  The text is available in English and in
>  <par>
>    <video src="video.mpg" clip-end="3s"/>
>    <switch> <!-- captions or subtitles  in Dutch -->
>      <text src="data:,Hallo, Joe."
>       system-captions="on"
>       system-language="nl"/>
>      <text src="data:,Hallo, Joe."
>       system-overdub-or-caption="caption"
>       system-language="nl"/>
>      <text src="data:,Hello, Joe."
>       system-captions="on"/>
>    </switch>
>  </par>
>  <par>
>    <video src="video.mpg" clip-begin="3s" clip-end="6s"/>
>    <switch> <!-- captions or subtitles in Dutch -->
>      <text src="data:,Hoe gaat het?"
>       system-captions="on"
>       system-language="nl"/>
>      <text src="data:,Hoe gaat het?"
>       system-overdub-or-caption="caption"
>       system-language="nl"/>
>      <text src="data:,How are you?"
>       system-captions="on"/>
>    </switch>
>  </par>
>This is, obviously, more SMIL code than in the original example.
>However, the total amount of code used here is smaller.  The original
>example also uses two external .rtx streams, which contain time code,
>most of which is redundant between the multiple text files.  The code
>here is smaller than the original SMIL code and the .rtx code
>Another advantage is that fewer files are used.  Originally, there
>was a .rtx stream for each language.  Here, no external files are used
>for the text.

For me, the URI with data still seems a bit odd. Why not let authors to
write content for the text objects or links?

>A third advantage is that here the timing code controls both the video
>and the text together, whereas in the original example the timing code
>embedded in the text stream controlled only the text.  With the SMIL
>encoding, if the video is slowed down, the timing of the text display
>slows with the video.


>This playing well would rely on browsers being able to seamlessly join
>the sequential video clips to play like one video.  This would
>probably be better encoded with pausing in SMIL Boston.  Again,
>Geoff's posting applies here [3].
>[1] http://www.w3.org/WAI/EO/NOTE-smil-access
>[2] http://www.w3.org/TR/smil-boston/
>[3] http://lists.w3.org/Archives/Public/www-smil/1999JulSep/0043.html
>[4] http://www.ics.uci.edu/pub/ietf/uri/
>[5] http://www.ics.uci.edu/pub/ietf/uri/rfc2397.txt
>[6] http://lists.w3.org/Archives/Member/symm/1999Jul/0033.html
>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
Received on Wednesday, 11 August 1999 17:53:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:46 UTC