Re: [css3-speech] LC comment: why no play-during or equivalent?

Hello Greg
just a heads-up to let you know that the CSS Working Group has reviewed this issue, and the consensus is to reject the 'play-during' feature request in this version (Level 3) of the CSS Speech Module. However, the WG appreciates that this feature might be considered for addition into the next major revision of the module.

As per the W3C process, you may choose to accept this resolution, or you may decide to raise an objection. Please let us know.

Kind regards, Dan

On 12 Oct 2011, at 16:27, Daniel Weck wrote:

> Hi Greg, 
> 
> [Q1]
> I think that the original intent was to provide some kind of CSS alternative for the "bgsound" element. The very first draft of the CSS Speech Module did not carry over the 'play-during' property from the informative CSS2.1 Aural Stylesheet Appendix. I personally believe that this was a good design decision, as it contributes to narrowing the focus of CSS-Speech to mostly speech synthesis, instead of creating a general-purpose mechanism to "inject" arbitrary audio content in markup documents (especially audio content that plays in parallel to potentially several other aural streams).
> 
> The audio "cue" feature of CSS-Speech is really limited to short auditory signals surrounding a TTS prompt. Of course, the specification cannot (and should not) enforce rules about the length of pre-recorded audio cues, but the mutually-exclusive nature of the sequential aural output indirectly guarantees that authors will not abuse the "cue" feature, as an alternative to (for example) HTML5's audio element.
> 
> For the sake of clarity, I should point-out that SSML1.1 actually provides a rich 'audio' element (resembling the equivalent SMIL element) with fallback TTS content, but this feature does not correspond to the CSS2.1 (informative) 'play-during' property, as it takes part in a *sequence* of aural prompts (i.e. no parallel/mixed audio output).
> 
> [Q2]
> The 'content' CSS property can indeed be used to generate or replace content within the markup document, and the CSS3-Speech specification informatively acknowledges that authors may use this general-purpose feature to "inject" an audio clip within a text-only element. As you pointed-out, this is not suitable for "parallel" playback of an ambient background sound, which I believe is a sane design decision that enables CSS3-Speech to remain simple and implementable. The 'cue-before' and 'cue-before' properties already provide a mechanism to announce particular markup structures, so I don't see "background audio" as a strict imperative right now.
> 
> [Q3][Q4]
> CSS selectors with interactivity-related dynamic pseudo-classes can be used to refer to an activated/focused form element.
> The requirement to convey the state of form elements (e.g. checked box) to the styling mechanism is not fulfilled by Level3 Selectors, but Level4 (currently under development as well) introduces "state" pseudo-classes. At any rate, this is not within the scope of the Speech Module.
> 
> As for your last point about default user-agent stylesheets, and the possibility for users to configure preferred settings: CSS defines the underlying mechanism, not the user-interface. Once again, perhaps a WCAG-led activity could define author and user-agent guidelines?
> 
> Please let us know whether this response is satisfactory.
> Kind regards, Daniel
> 
> On 1 Oct 2011, at 04:14, Gregory Rosmaita wrote:
> 
>> aloha!
>> 
>> Question 1. why was the ACSS and CSS 2.1 Appendix A 'play-during'
>> mixing property
>> 
>> http://www.w3.org/TR/CSS21/aural.html#mixing-props
>> 
>> removed from css3-speech?
>> 
>> 
>> Question 2. css3-speech Section 9 "Cue properties" provides for an
>> aural icon to be played before an element is encountered or after
>> that element has been encountered within the audio box model:
>> 
>> QUOTE cite="http://www.w3.org/TR/css3-speech/#cue-props"
>> The 'cue-before' and 'cue-after' properties specify auditory icons
>> (i.e. pre-recorded / pre-generated sound clips) to be played before
>> (or after) the selected element within the audio "box" model.
>> UNQUOTE
>> 
>> additionally, css3-speech provides a (non-normative) means of playing
>> a sound clip of a marked string of text
>> 
>> QUOTE
>> In a similar way, text strings in a document can be replaced by a
>> previously recorded version.
>> 
>> Example XIII
>> 
>> In this example - assuming the format is supported, the file is available
>> and the UA is configured to do so - a recording of Sir John Gielgud's
>> declamation of the famous monologue is played. Otherwise the UA falls
>> back to render the text using synthesized speech.
>> 
>> .hamlet { content: url(./audio/gielgud.wav); }
>> ...
>> <div class="hamlet">
>> To be, or not to be: that is the question:
>> </div>
>> UNQUOTE
>> 
>> but what if the author wanted to provide a subtle ambient background
>> sound to indicate, for example, that the string of text currently being
>> spoken is contained in a specific type of containing element, such as
>> BLOCKQUOTE, Q, or EM?
>> 
>> 
>> Question 3. what of aural events one might want to associate with
>> interactive elements, such as edit boxes and other form controls, so
>> that as long as the user is activating a form control -- for example, a
>> sound that plays simulating typewriter keystrokes when input is
>> received by a TEXTAREA to inform the user/reinforce for the user
>> that text is being entered into a TEXTAREA (this is intended to
>> aid those with cognitive issues who are aided by supplemental
>> speech, as well as those screen reader users who don't mind
>> aural clatter if it assures them that their input is actually
>> being input into the interactive element (such as the TEXTAREA
>> in this example)
>> 
>> 
>> Question 4. what is an author or a user of a client-side stylesheet to
>> do if one wants to associate a sound with a change in state of a form
>> control (such as a radio button or check box) in an accessible manner
>> WITHOUT using javascript?
>> 
>> use of javascript to provide this function does not suffice, as it
>> prevents a user from associating an aural event to a change in state
>> via a client-side stylesheet -- the more a user can control aural
>> events via a simple syntax such as provided by CSS/css3-speech, the
>> better the user experience...
>> 
>> i hope that i made my concerns clear -- that:
>> 
>> 1) the css3-speech cue properties are insufficient, as there is no
>> "play-during" or equivalent option available to authors and users;
>> 
>> 2) how does one indicate state (e.g. checked/unchecked - on/off)
>> 
>> 2a) as an author, i want to be able to serve up a variety of aural
>> overlays, much in the way that many sites allow users the option to
>> switch font, font-size, contrast, etc. -- by such means, i can offer
>> more verbose, less verbose, and audio-only overlays so that users
>> have a choice of the amount of aural information they receive via
>> css3-speech
>> 
>> 2b) as a user, i want to be able to use css3-speech to control
>> client-side aural stylesheets -- control over which could easily be
>> turned into a user-friendly "wizard" or "property sheet" type interface
>> so that users don't have to know CSS in order to exercise control over
>> aural events, as well as providing a user with a consistent aural
>> experience which that user can tailor to his or her needs
>> 
>> THANK you for your work on moving css-speech towards rec status!
>> 
>> gregory
>> -----------------------------------------------------------------
>> PEDESTRIAN, n. The variable (and audible) part of the roadway for
>> an automobile.          -- Ambrose Bierce, The Devil's Dictionary
>> -----------------------------------------------------------------
>>      Gregory J. Rosmaita, gregory.rosmaita@gmail.com
>>       Camera Obscura: http://www.hicom.net/~oedipus
>>    Oedipus' Online Complex: http://my.opera.com/oedipus
>> -----------------------------------------------------------------
>> 
>

Received on Wednesday, 19 October 2011 23:39:40 UTC