Re[2]: [CSS21] [css3-speech] More specific about alternatives to 'cue' sounds

<note
class="inTransmittal">

This message relates to the comment logged at

http://lists.w3.org/Archives/Public/www-style/2007Dec/0137.html

.. and specifically the response at

http://lists.w3.org/Archives/Public/www-style/2007Dec/0142.html

Please consider the 2nd try edit proposed below, for the
reasons discussed below.

This request has rough consensus in the PFWG.

Al
/chair, PFWG

</note>

 >Al Gilman wrote:
 >>
 >>Currently, the CSS2.1 Last Call draft's Appendix A, states:
 >>
 >>This is insufficient from the point of view of those who benefit
 >>from aural styling; this definition should contain even more
 >>robust verbiage than is contained in Section 19 of CSS2:
 >>...
 >>The Protocols & Formats working group proposes that the extant  
text in
 >>the CSS2.1 Candidate Recommendation draft be amended as follows:
 >
 >Al, CSS2.1 is currently a Candidate Recommendation, not a Last Call
 >Working Draft; furthermore Appendix A is only informative. Your
 >proposed text doesn't seem to say anything different from what is
 >there, it only adds more examples. I can suggest that the CSS3 Speech
 >editor consider adding some more example text to the CSS3 Speech
 >draft
 >   http://www.w3.org/TR/css3-speech/
 >but I'm not convinced that we need to make this change for CSS2.1.

** on the process:

Yes, this is a Candidate Rec version, and yes, this is a 'should' in an
informative appendix.  That status cuts both ways.

Let's agree that we don't want to make changes that alter the validity
of the Implementation Report one whit.

That still means we can, and PFWG believes we should, capitalize on
the opportunity to tell implementers what they should actually do
when the words read like a statement of what they should do.

Yes, in the future with CSS3, WAI-ARIA politeness, intent-based
events, and all there will be better things one can do; but even with
today's markup and delivery context there are better and worse ways
to recover from this failure of the designed presentation.

** on the product:

There are two use cases that are important from an accessibility
perspective:

   (1) the sonicon or recorded speech that is to be cued informs the
user of a mode or state change in the application.  Eyes-free users
are dependent on these events to understand dialog progress and
errors.  So it is indeed important that the CSS implementation
perform due diligence to try to get an event into the user's perception.

(2) the user hears poorly or not at all.  In this case an audio alert
will not suffice, and it is important to seek out and follow user
preferences.

What we would recommend at this time is that the CSS implementation
use the Operating System services to notify the user in cases where
the author has programmed via @cue a sound to be played, and that
play-a-sound action can't be done for any reason.

This is robust in that if anyone has a way to reach the user, the OS  
does;
and further it cooperates with the best-available-today way of finding
and respecting the user's preference as to alert alternatives.

** retry on proposed language.

From:
<q
cite="http://www.w3.org/TR/2007/CR-CSS21-20070719/aural.html#propdef- 
cue">
If a user agent cannot render an auditory icon (e.g., the user's
environment does not permit it), we recommend that it produce an
alternative cue.
</q>

To:
<draft
class="suggested forExample">
If a user agent cannot render an auditory icon for any reason, it
should produce an alternative cue, respecting user preferences as to
alerting modalities. This can generally be achieved by working
through the operating system's event-alerting facilities.
<draft>

Received on Monday, 21 January 2008 16:22:19 UTC