(forwarded to add cc: list requested in message requesting review)
Forwarded message 1
Review of Accessibility Features of SMIL @:
http://www.w3.org/WAI/EO/NOTE-smil-access-19990726
+++++++++
Reminding authors and implementors about the accessibility features of SMIL
1.0 is incredibly important. This note offers good reasons for authoring
accessible content and provides many straight-forward examples.
While not intending to denigrate the challenge that HTML authors have in
making typical HTML content accessible, long-form multimedia -- and in
particular long-form streaming multimedia -- is an order of magnitude more
difficult to author. Long form multimedia content is often more difficult,
time consuming and thus more expensive to produce. Providing accessible
long-form multimedia content involves complex synchronization and timing
issues which are more resource intensive to modify than a typical web page.
As the Intro mentions, much of the onus for creating accessible content is
on the author rather than the SMIL language. There are several issues to
consider in order to make accessible content more prevalent on the Web:
* authoring resources (time, expertise, content, etc.) to create
multiple/alternative presentations
* protecting the presentation of author's content
* support for accessible content in current tools
Authoring SMIL presentations for a single target low-bandwidth audience can
often be challenging. Choreographing different presentations for different
audiences -- and catering to the different needs of different audiences--
means essentially designing multiple presentations. Authors may not have
reasonably equivalent media, and could be forced to
create more complex presentations than the original 'non-accessible'
content. If accessible content is to be the norm, content providers must
account for the considerable time required to author accessible content.
Also, translation tools for non-accessible to accessible content are needed
to reach widespread deployment. Even with translation tools, the testing
of resulting content is a considerable expense that should be accounted for.
SMIL authors go to great lengths to design the layout and playback of their
presentations. Authors want their presentations to look and play as they
intended. The Zoom level feature of RealPlayer (double-size and
full-screen) provides an improvement for the visually impaired without
altering the design of the presentation. RealPlayer also provides controls
to allow the user to modify the display colors of video and to customize
the audio playback quality. (As a side example, I've heard some HTML
authors complaining that the font sizing feature of web browsers radically
alters their page design.) Significant evangelism will need to occur to
convince many authors of the value of letting audience members alter
content to suit their needs.
Tools (including RealNetworks') could -- and should -- make it easier to
create accessible content. Support for discrete equivalents (alt,
longdesc, title, abstract, author) should be integrated into generated SMIL
presentations. (Patrick raised the issue of providing multilanguage
attributes...)
Specific points:
- "...players must allow them to speed up, slow down, or pause a presentation"
Although full presentation playback control could be done independent of
SMIL, this is a non-trivial feature for playback engines to implement and
has bandwidth implications for streaming media.
- "recommend style sheets for a number of reasons..." (section 3.1)
How do style sheets "ensure that the user has full control of the
presentation"?
How is "document and site management" an accessibility feature or
requirement?
- "SMIL players should allow users to turn on and off support for opening
new windows" (section 4.4)
This does not seem like a useful requirement. Multiple windows may
provide more detailed info or an alternate presentation of the media. Web
browsers do not impose such a restriction.
- alt and longdesc can be added to SMIL files played back in RealPlayer,
but they conflict with RealSystem's autoupdate feature. RealPlayer
attempts to automatically download new components when a new media type is
encountered that RealPlayer is unable to render. If no component is
available, the presentation will stop rather than using alt.
- Minor note: RealText streams now use the extension .rt.
- Last example in section 2.2.3 seems to use the same file
(closed-caps-es.rtx) for both test attributes. Should the second one be
subtitles-es.rtx?
--Bridie