Re: html code element and speech output

aloha, charles!

CMN: As Joe pointed out, messing around a user's speech setup is a pretty 
bad idea in general, so it makes sense to use careful styling based on 
well-described types of objects rather than just assigning style to each 
element. This gives the user the easiest path to override a style and 
provide their own. It would also be helpful if, there were good editors for 
CSS available that handled audio style sheets by example rather than by 
making the user learn the code to write. (this applies to visual properties 
too...)

GJR: well, i've been screaming for simple wizard-type interfaces for 
client-side CSS adjusting/tailoring for years, so you won't get any 
argument from me on that front, but i think you missed my point -- visual 
UAs have default stylesheets which combine to provide a visual shorthand 
for the user -- a user recognizes a radio button not because the document 
source reads:
         <input type="radio" ...>
but because he or she recognizes that, iconically, radio buttons are round, 
as opposed to checkboxes which are square -- one does not even need to know 
the jargon -- only that round objects are exclusive choices (choose one of 
many) while squares signify multiple options (choose as many as apply)

but radio buttons are not intrinsically round, nor are checkboxes 
inherently square (despite the implicit connotation contained in the name) 
-- they have come to be ubiquitously rendered in these forms because, 
through usage and custom, as well as for consistency's sake, people have 
come to associate round objects with exclusive choices and squares with 
multiple choices...    they are simply tangible, and specific, 
manifestations of logical concepts...  which is why i cannot agree with 
your statement quote well-described types of objects rather than just 
assigning style to each element unquote -- KBD is not equivalent with CODE 
(if they were, one would have been/should be deprecated) and "form 
controls" is too broad a "well-described type of object"

an audio browser, therefore, MUST provide 2 things:

1) a default stylesheet in which EACH element defined for the markup 
languages it supports has a DEFAULT aural style/event associated with it -- 
otherwise, how is the user to know that a radio button has been 
encountered?  obviously, all such conventions MUST be documented, which is 
why i don't understand your invocation of joe's warning against changing 
aural properties server-side -- any aural browser MUST provide aural 
conventions slash shorthand, which is what, i believe, was the point of 
wendy's inquiry -- given the use of elements that are visually indicated 
through font property changes, do aural browsers provide an equivalent 
aural indication, or, at least, the means of providing individualized aural 
styling for such indicators?  even the enunciated text-string "radio 
button" is aural styling -- why should i not be able to substitute a bright 
ding for unchecked, a dull ding for checked, and a brief snippet of static 
to indicate a greyed-out radio button?  and why shouldn't someone who finds 
the association defined by the aural UA's developer counter-intuitive be 
able to reverse them or change them altogether?)

2) a means of changing the default aural stylesheet, as an implementor's 
idea of a "clear and unambiguous" aural icon may not be readily perceptible 
by all users or may cause confusion due to differing aural conventions in 
other commonly used applications -- that is the flip side of joe's argument 
about changing a visitor's speech properties, and my point about an 
"inverse" property somewhat analogous to the "inherit" 
property...  moreover, i do not expect many page authors, outside of a 
small self-selecting group, to provide any (let alone extensive) aural 
styling to the document, let alone provide the transformation engine 
outlined in the first paragraph of your response -- rather, i expect that 
some level of aural styling be provided by the self-voicing technology, 
which would include default values for all defined elements, most of which 
would probably be null values (not many people, for example, would want 
paragraph breaks announced, although the capacity to do so with simple 
aural styling on the client side is an absolute necessity, so that anyone 
using an aural browser can obtain the same information which is visually 
conveyed by a blank line between text blocks...

and finally, on behalf of love, i must inquire: will the process you 
outlined in your first paragraph be available in the next six months?  i 
remain a staunch advocate of ACSS because (a) a very-well defined 
vocabulary exists, (b) it has been implemented, (c) it was designed to be 
compatible with text-to-speech technologies similar to those which are 
already widely deployed...  the grammar and concepts are easily understood, 
and would translate well into an aural styling wizard or menu-driven 
interface, so the mechanism involved in providing configuration over aural 
styling (on both a global and per-document-instance basis) need not be 
technically oriented and the learning curve rendered far less onerous, gregory

At 11:19 AM 4/17/02 -0400, Charles McCathieNevile wrote:
>Another approach to using ACSS in tools would be to convert the document to
>XHTML, and then to turn it into an intermediate XML through the use of local
>javascript, and then to convert that to Speech Synthesis Markup Language
>(SSML) through the use of XSLT, and find a tool that uses this new language
>(being developed as part of the Voice Browser work at W3C.
>
>As Joe pointed out, messing around a user's speech setup is a pretty bad idea
>in general, so it makes sense to use careful styling based on well-described
>types of objects rather than just assiging style to each element. This gives
>the user the easiest path to override a style and provide their own. It would
>also be helpful if, there were good editors for CSS available that handled
>audio style sheets by example rather than by making the user learn the code
>to write. (this applies to visual properties too...)
>
>Chaals
>
>On Tue, 16 Apr 2002, Gregory J. Rosmaita wrote:
>
>   aloha, wendy!
>
>   as you know, i'm not quite up to snuff on the real world, but i can tell
>   you that you can define any number of aural properties for CODE using the
>   speaking properties defined in section 19 of the CSS2
>   specification...  most germane are the speech properties
>   "speak-punctuation" and "speak-numeral" which are defined in section 19.9,
>   as follows:
>
>   <quote href="http://www.w3.org/TR/CSS2/aural.html#speech-props">
>   19.9 Speech properties: 'speak-punctuation' and 'speak-numeral'
>
>   An additional speech property, speak-header, is described in the chapter on
>   tables
>
>   'speak-punctuation'
>
>   Value: code | none | inherit
>   Initial: none
>   Applies to: all elements
>   Inherited: yes
>   Percentages: N/A
>   Media: aural
>
>   This property specifies how punctuation is spoken. Values have the
>   following meanings:
>
>   code
>   Punctuation such as semicolons, braces, and so on are to be spoken 
> literally.
>
>   none
>   Punctuation is not to be spoken, but instead rendered naturally as various
>   pauses.
>   </quote>
>
>   here's an example of how one might use CSS2 to have an aural-CSS-aware
>   browser indicate items marked-up using the CODE element:
>
>   <example>
>   @media aural {
>   code { voice-family: robot, male;
>            speak-punctuation: code;
>            speak-numeral: digits; }
>   }
>    >/example>
>
>   note 1: i defined 2 values for voice-family (1) a specific-voice value and
>   (2) a generic-voice value; - what i'd really like to do is  be able to
>   define inverse relationships, so that, for example, if a user had the aural
>   browser's default voice set to "female", when the UA encountered the CODE
>   element, it would aurally "reverse fields" and speak the text marked up as
>   CODE in a "male" voice -- obviously, this would be handy in other (mostly?
>   exclusively?) binary situations, as well as an ideal way to ensure that
>   changes in background and/or foreground color don't collide with client
>   side settings (in other words, simply reverse the "color:" and
>   "background:" values when rendering a block marked as "foo" or defined by
>   the FOO element)
>
>   note 2: one could use a host of other aural properties to aurally demarcate
>   CODE...a simple pitch change, for example, or a cue-before and cue-after
>   event, or a change in the voice characteristics values, such as stress or
>   richness...  note that what are generally classed as "synthesized voices"
>   are pre-set combinations of voice characteristics - for more details on all
>   this jargon, consult the URI cited above...
>
>   of course, only an aural-CSS-aware client/application would provide the
>   desired aural effect (a voice change) when encountering this example
>   markup, although providing the desired effect (a simple voice
>   characteristic change) as the result of a DOM call is not only possible,
>   but essential, in my opinion -- assistive software needs to be aware of the
>   UA's generic values (defined in the base style sheet, which for most users,
>   if not in most browsers, is immutable) and provide analagous values in
>   whatever output modality is required...  wherever generic classes have been
>   defined by the UA (such as for CODE, Q, KBD, SAMP, etc.) an AT needs to
>   provide a means of identifying those classes, as well as controlling the
>   means of identification -- think of it as equivalent content, for the
>   default rendering of CODE as monotype IS content!
>
>   of course, there are also low-tech solutions to the problem, such as screen
>   scraping, but they are not as efficient nor can they ever be as
>   interoperable as an AT that is not only DOM-aware, but CSS-aware...
>
>   just my 2 cents, american, as someone who mostly uses IE6 or lynx in
>   conjunction with JAWS 4.02, from which no aural indication of
>   content-related elements is obtainable, gregory.
>
>   At 03:27 PM 4/16/02 -0400, you wrote:
>   >Hello,
>   >
>   >Could someone tell me if Jaws, Window Eyes, Home Page Reader, et al give
>   >some indication when html code elements have been encountered?
>   >
>   >e.g. here's a code snippet
>   >
>   >here's some text
>   >here's some code
>   >When "here's some code" is read - does it give indication that this is
>   >code?  Visually, it is usually shown in a courier font (to make it look
>   >more machine-like i suppose).  Just wondering if there is also some audio
>   >indication.
>   >
>   >Could you please include the version and platform of the product that you
>   >are using?
>   >
>   >Thanks,
>   >--wendy

--------------------------------------------------------------------
ABSURDITY, n.  A statement or belief manifestly inconsistent with
one's own opinion.       -- Ambrose Bierce, _The Devils' Dictionary_
--------------------------------------------------------------------
          Gregory J. Rosmaita, <unagi69@concentric.net>
Camera Obscura:             http://www.hicom.net/~oedipus/index.html
VICUG NYC:            http://www.hicom.net/~oedipus/vicug/index.html
Read 'Em & Speak:     http://www.hicom.net/~oedipus/books/index.html
--------------------------------------------------------------------

Received on Wednesday, 17 April 2002 13:16:46 UTC