- From: Mitchell Evan <mtchllvn@gmail.com>
- Date: Sun, 17 May 2015 17:28:04 +0000
- To: lwatson@paciellogroup.com, Rodrigo Prestes Machado <rodrigo.prestes@gmail.com>, w3c-wai-ig@w3.org
- Message-ID: <CAK=xW6sNtcFCD1gakqT_VoOJZ0U4nCH95oOCXuBdhpzbhUaABQ@mail.gmail.com>
Rodrigo, Consider a two part approach: semantics plus CSS speech. In the context of your web site, would it make sense to use the "alert" role for your live regions? This role combines semantics with aria-live behavior. http://www.w3.org/TR/wai-aria/roles#alert Or possibly the "note" role? I'm not sure about AT support for this one, but it might makes sense from a code perspective. http://www.w3.org/TR/wai-aria/roles#note Either way, the screen reader should announce the semantics, to help distinguish the live region announcement from other announcements. And the semantics should work equivalently in Braille displays and speech. On top of the semantics, it would be great to add CSS speech properties as a progressive enhancement. It would help very few users today: only Opera with optional settings. ( http://www.css3.info/preview/speech/ ) The real win is if you can show us a useful real-world example of CSS3 speech, then we use your example to file defects against the more popular browsers and AT. On Sun, May 17, 2015 at 5:21 AM Léonie Watson <lwatson@paciellogroup.com> wrote: > *From:* Rodrigo Prestes Machado [mailto:rodrigo.prestes@gmail.com] > *Sent:* 17 May 2015 01:09 > > Thank you Chaals and Phill!, > > > > I understood that JAWS can use different voices, for example, > differentiate an operating system menu and an HTML content. However, I was > thinking to change the sound of live regions (notification system) can be a > useful feature for some users. For example, in text editor in Google Docs, > there is a constant need for user perception, if JAWS enable diferente > voices to live regions, it can create a different usability approach, Is it > a bad ideia? > > > > It’s a good idea, but it isn’t possible right now. > > > > Jaws can be configured to use different voices for many different things. > It isn’t something that can be done by a website author/developer though, > it has to be done by the Jaws user. > > > > This is what the Aural CSS specification (now the Speech specification) is > intended to do [1]. Unfortunately it isn’t supported in any browser, so for > the time being there is no way for a website author to request that the > screen reader use a particular voice or speech profile. > > > > Léonie. > > [1] http://www.w3.org/TR/css3-speech/ > > > > Em 13/05/2015, à(s) 10:56, Phill Jenkins <pjenkins@us.ibm.com> escreveu: > > > > yes, > you can try multiple voices with JAWS (screen reader) and MAGic (screen > magnifier with speech), even in "40-minute demo mode". > see > http://doccenter.freedomscientific.com/doccenter2/doccenter/rs25c51746a0cc/voiceprofiles/02_voiceprofiles.htm > > For example, one can change the voice in context, such as for any of the > following: > *Adjust combo box*. The Adjust combo box defaults to All Contexts, but > here you can also choose the following voices to change: > > - PC Cursor Voice > - JAWS Cursor Voice > - Keyboard Voice > - Tutor and Message Voice > - Menu and Dialog Voice > > > So if one changed the settings for the voice for Menu and Dialogs, they > would "sound different" from regular text on the page/app. I've actually > done this when training sighted users to user JAWS as a test tool so they > "hear" a different voice for different controls and labels vs regular text; > kind of audio styling to match the visual styling. As you can imagine > however, the JAWS voice is still odd sounding to the first time listener, > so we emphasize the visible lists of links and controls list that JAWS > displays. > > Having said all this, I still believe that 'voice settings' are generally > the assistive technology's (AT's) and end user's responsibility, and NOT > the web author's. Remember, we're not creating a one-size fits all audio > version of a web site; authors and developers are *enabling* non-visual > access to a web app. Enabling is both a design and coding practice. Novice > screen reader users will "turn on" all the vebosity so they can to "learn", > while power screen reader users will turn off most of the verbosity > settings. Quality AT like JAWS and MAGic allow the end user (and sighted > testers) to create "profiles" that they can switch to in different > contexts. > ____________________________________________ > Regards, > Phill Jenkins, > IBM Accessibility, created > 'IBM Screen Reader for DOS' > 'IBM Screen Reader for OS/2' > 'IBM Home Page Reader' > > >
Received on Sunday, 17 May 2015 17:28:37 UTC