Forwarded message 1
This post is a response to the draft for "Accessibility Features of
SMIL".
SMIL BOSTON
-----------
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].
OPENING NEW WINDOWS
-------------------
Can WAI offer any suggestions for player implementors on how to best
handle opening new windows for users that don't favor them?
USEFUL NAVIGATION MECHANISMS
------------------------------
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.
USE OF CSS
----------
[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.
FORMATTED TEXT
--------------
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.
AUDITORY DESCRIPTIONS
---------------------
> 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.
> 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.
SMIL TIMING CODE IN THE EXAMPLES
--------------------------------
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.
The primary advantage of encoding the timing in SMIL is that you can
use implicit timing and adaptive timing instead of only absolute
timing.
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
Dutch.
<seq>
<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>
</seq>
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
combined.
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.
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
--
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