- From: Marc Silbey <marcsil@windows.microsoft.com>
- Date: Thu, 17 Jan 2008 19:03:08 -0800
- To: Al Gilman <Alfred.S.Gilman@IEEE.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>
As promised, I want to follow-up on my action item; research APIs capable of communicating CSS-generated events to the operating system (http://www.w3.org/2008/01/09-pf-minutes.html#action01). User agents that run on Windows can call the MessageBeep() API to play a system sound like a simple beep. You can find more details on the MessageBeep() API in the following MSDN document: http://msdn2.microsoft.com/en-us/library/ms680356(VS.85).aspx -----Original Message----- From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf Of Al Gilman Sent: Sunday, January 06, 2008 11:14 AM To: wai-xtech@w3.org Subject: DRAFT Re: [CSS21] [css3-speech] More specific about alternatives to 'cue' sounds <note class="inDraft"> I volunteered to attempt a rewrite of our reclaimer as regards the comment [CSS21] More specific about alternatives to 'cue' logged at http://lists.w3.org/Archives/Public/www-style/2007Dec/0137.html Please consider this reply to the response at http://lists.w3.org/Archives/Public/www-style/2007Dec/0142.html </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> >~fantasai <note class="questions forWAI"> Can someone confirm that the CSS code which is running as an installed application typically has the ability to launch notification events through the OS? Can these be mild? Considering all the work we have put into event firehose management in the live-region (politeness) stuff, it does not seem appropriate to make every failure to play a cued sound a rude event. </note> Al /for XTECH re-review and PFWG action
Received on Friday, 18 January 2008 03:03:30 UTC