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

Re: [Fwd: Review of accessibility note]

From: Marja-Riitta Koivunen <marja@w3.org>
Date: Thu, 12 Aug 1999 02:56:44 -0400
Message-Id: <3.0.5.32.19990812025644.009d9210@localhost>
To: Philipp Hoschka <ph@w3.org>, ij@w3.org, symm@w3.org, dd@w3.org, wai-liaison@w3.org, w3c-wai-eo@w3.org, jbrewer@w3.org
At 10:57 AM 8/10/99 +0200, Philipp Hoschka wrote:
>(forwarded to add cc: list requested in message requesting
review)Return-Path: <symm-request@w3.org>
>Received: from sophia.inria.fr by www45.inria.fr (8.8.8/8.8.5) with ESMTP
id BAA04924 for <hoschka@www45.inria.fr>; Tue, 10 Aug 1999 01:31:44 +0200
(MET DST)
>Received: from www10.w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id
BAA12630; Tue, 10 Aug 1999 01:31:42 +0200 (MET DST)
>Received: from www19.w3.org (www19.w3.org [18.29.0.19])
>	by www10.w3.org (8.9.1/8.9.1) with ESMTP id TAA20712;
>	Mon, 9 Aug 1999 19:31:41 -0400 (EDT)
>Received: (from daemon@localhost)
>	by www19.w3.org (8.9.0/8.9.0) id TAA18358;
>	Mon, 9 Aug 1999 19:31:32 -0400 (EDT)
>Resent-Date: Mon, 9 Aug 1999 19:31:32 -0400 (EDT)
>Resent-Message-Id: <199908092331.TAA18358@www19.w3.org>
>Message-Id: <3.0.5.32.19990809163615.015f3cc0@prognet.com>
>X-Sender: bridie@prognet.com
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Mon, 09 Aug 1999 16:36:15 -0700
>To: symm@w3.org
>From: Bridie Saccocio <bridie@real.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Subject: Review of accessibility note 
>Resent-From: symm@w3.org
>X-Mailing-List: <symm@w3.org> archive/latest/303
>X-Loop: symm@w3.org
>Sender: symm-request@w3.org
>Resent-Sender: symm-request@w3.org
>Precedence: list
>X-Mozilla-Status2: 00000000
>
>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.

I agree. Some things are more important and some things can be made more
easily than others. The priorities are discussed in WAI/User Agent group.

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

Sounds like a good feature. In some cases it might be that something else
is needed as well.

>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...)
>
I agree.

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

OK. I think it is still a goal from accessibility viewpoint and priorities
are discussed in WAI/UA.

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

Users can define their own style sheets that take their needs into account.
We will rephrase some of the CSS stuff as CSS is not supported by the SMIL
players yet.

>	How is "document and site management" an accessibility feature or
>requirement? 

It is not but it does help authors to make changes.

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

This helps e.g blind users who don't see windows popping out. They either
should use the same window or inform the users about the new windows and
help users to navigate between them.

(Actually sometimes also the seeing users can find it distracting if there
is several windows created and stopped without the user control.)

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

Philipp already answered this. 

>- Minor note: RealText streams now use the extension .rt.

OK. We should change this.

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

This is explained more carefully now.
Received on Thursday, 12 August 1999 02:59:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:26 GMT