W3C home > Mailing lists > Public > wai-xtech@w3.org > May 2007

Re: [navigation] premise: client software affords context prompting from labels of ancestors

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 17 May 2007 22:00:07 -0400
To: wai-xtech@w3.org
Message-Id: <20070518015353.M52212@hicom.net>

aloha, al!

although, i'm not sure what to make of the term quote common practice in 
screen-readers unquote, the answer to your question as to where the 
responsibility for providing contextual information depends upon the 
screen reader one is using...

most screen readers i am familiar with have a contextual information or 
extended information mode -- usually with 2 levels of granularity:

1. repeat item with focus;

2. put item with focus in context

in the case of a tree view, the first inspection command will provide 
the user with either the content on the screen, or in the case of an 
image or graphical link, the ALT text defined for it;  the second 
will put the object in context, for example:

Tree View
Item Seven of Twelve (collapsed)

so one receives contextual and state information; take the following
example:

<form id="f1" action="nothing">
<fieldset>
<legend>Indicate the Level of Your Satisfaction with Our Customer 
Service</legend>
<br />
<label for="f1a"><input type="radio" id="f1a" value="es" 
title="Extremely Satisfied (option 1 of 6)" /> Extremely Satisfied</label>
<br />
<label for="f1b"><input type="radio" id="f1b" value="vs" 
title="Very Satisfied (option 2 of 6)" /> Very Satisfied</label>
<br />
<label for="f1c"><input type="radio" id="f1c" value="s" checked="checked" 
title="Satisfied (option 3 of 6, checked by default)" /> Satisfied</label>
<br />
<label for="f1d"><input type="radio" id="f1d" value="sd" 
title="Somewhat Dissatisfied (option 4 of 6" /> Somewhat 
Dissatisfied</label>
<br />
<label for="f1e"><input type="radio" id="f1e" value="vd" 
title="Very Dissatisfied (option 5 of 6)" /> Very Disatisfied</label>
<br />
<label for="f1f"><input type="radio" id="f1f" value="never" 
title="I'll Never Do Business with you again!" /> I Will Never Do 
Business With You Again</label>
</fieldset>
</form>

if one navigates to one of the INPUT fields and uses a hot-key 
command to query the element with focus' contextual information, 
one should hear:

Indicate the Level of Your Satisfaction with Our Customer Service
radio button 5 of 6
Very Dissatisfied
not checked

that is:

1. the legend defined for the fieldset (gives grouping context and 
relationship);

2. the element type, label, and state

however, it should be noted that this attempt to gain contextual 
information is not (or is VERY rarely) extended to hyperlink 
text, especially where one has used a title attribute to provide 
expended information about the hyperlink, such as:

<a href="http://www.foo.br" title="Download ApplicationX Now! (32.8 MB)"
><img src="../images/download.png" alt="Download Now!"></a>

reviewing the object with focus (the image alt-texted "Download 
Now!") usually does not include any of the information contained in 
the title defined for the hyperlink, ALT taking precedence over 
TITLE by default in most screen readers.  even in the case of 
regular hyperlink text, one cannot count on the title attribute to 
provide sufficient differentiation between repeated link text, 
such as multiple instances of the hyperlink text quote login unquote
at an online banking interface, where the terse hyperlink text is 
clarified by use of the title atttribute, as follows:

<a href="http://www.bank.com/pslogin.php" title="Login to Personal 
Savings"
>Login</a>

<!-- ... -->

<a href="http://www.bank.com/pclogin.php" title="Login to Personal 
Checking"
>Login</a>


<!-- ... -->

<a href="http://www.bank.com/sbclogin.php" title="Login to Small Business 
Checking"
>Login</a>

<!-- ... -->

<a href="http://www.bank.com/mortlogin.php" title="Login to Mortgage 
Central"
>Login</a>

screen readers also need to (but do not currently) aurally indicate 
(optimally with an earcon but with an explicit label if that is the 
end user's choice) where abbreviation and acronym expansions are 
available,so that the user can query the abbreviated text or acronym 
to obtain its expansion...  currently, most screen readers offer the 
user a binary choice:

1. automaticallly expand abbreviations and acronyms
2. do not automatically expand abbreviations and acronyms

nor am i aware of a single screen reader capable of substituting the 
title defined for an instance of the HR element, on-the-fly or on 
demand or even of one which simply indicates that a logical seperator 
has been traversed; hence the importance of aural styling -- instead 
of passively waiting for screen-readerX or screen-readerY to implement 
more robust contextual querying, the user can be made aware of the 
existence of elements containing contextual information using the 
mechanisms that have been part of ACSS since it's inception: cue, 
cue-before, and cue-after...   in addition, CSS3's Speech Module 
offers a means of marking points or discrete parts of a document:

<q 
cite="http://www.w3.org/TR/css3-speech/#mark-props">

The mark properties allow named markers to be attached to the 
audio stream. For compatibility with SSML, this must conform to 
the xsd:token datatype as defined in XML Schema. Synthesis 
processors must do one or both of the following when encountering 
a mark:

1. Inform the hosting environment with the value of the mark's 
   name with information allowing the platform to retrieve the 
   corresponding position in the rendered output.

2. When audio output of the SSML document reaches the mark, 
   issue an event that includes the required name attribute of 
   the element. The hosting environment defines the destination 
   of the event. 

The mark properties have no audible effect on the speech and instead 
just serve to mark points in the stream.

Values have the following meanings:

<string> 
     A string to be used as the name of the mark. 

A good way of adding the marking properties could be by means of 
using the attr() function.

Examples:

h1 {mark-before: "section"}
 
p {mark-before: attr(id) }

Name: mark
  Value: [ <'mark-before'> || <'mark-after'> ]
  Initial: not defined for shorthand properties  
  Applies to: all elements  
  Inherited: no  
  Percentages: N/A  
  Media: speech 

The 'mark' property is a shorthand for setting 'mark-before' and 
'mark-after'. If two values are given the first value is 
'mark-before' and the second is 'mark-after'. If only one value 
is given, it applies to both properties.

The following two rules are equivalent:

div {mark-before: "start"; mark-after: "end" }
 
div {mark: "start" "end" }

</q>

(although i would prefer the string "header" as the mark-before H1 
in the first example)

the attr() function of CSS3's Speech module, alluded to in the 
text quoted above is defined thus:

<q 
cite="http://www.w3.org/TR/css3-speech/#content">

Inserted and replaced content

Sometimes, authors will want to specify a mapping from the source 
text into another string prior to the application of the regular 
pronunciation rules. This may be used for uncommon abbreviations 
or acronyms which are unlikely to be recognized by the 
synthesizer. The 'content' property can be used to replace one 
string by another. In the following example, the abbreviation is 
rendered using the content of the title attribute instead of the 
element's content:

Example:

abbr { content: attr(title); }
  ...
<abbr title="World Wide Web Consortium">W3C</abbr>

This replaces the content of the selected element by the string 
"World Wide Web Consortium".

In a similar way text-to-speach strings in a document can be 
replaced by a previously recorded version:

Example:

.hamlet { content: url(gielgud.wav); }
  ...
 
<div class="hamlet">
To be, or not to be: that is the question:
</div>

If 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 will be played, otherwise the UA falls back 
to render the text-to-speech with its own synthesizer.

Furthermore authors, or users in a user stylesheet, may want to add 
some information to ease understanding the structure for non-visual 
interaction with the document. They can do so by using the 
'::before' and '::after' pseudo-elements that will be inserted 
between the element's contents and the 'rest':

Example:

ul::before { content: "Start list: " }
ul::after  { content: "List end. " }
li::before { content: "List item: " }

This inserts the string "Start list: " before a list and the string 
"List item: " before each list item; likewise the string "List end: "
inserted after the list will inform the user that the list is 
finished.

Different stylesheets can be used to define the level of verbosity 
for additional information spoken by screen readers.

Detailed information can be found in the CSS3 Generated and Replaced 
Content Module [http://www.w3.org/TR/css3-speech/#CSS3GENCON].

Editor's note: The alphabet is specified via an at-rule to avoid 
problems with inappropriate cascades that can occur if the alphabet 
was set via a property.

ISSUE: should there be a CSS equivalent to the SSML <sub> element? 
This gives the author the means to replace one string with another 
as means to changing how something is spoken, e.g. "as-key" for 
"ASCII". A possible solution is a new CSS property 'say-instead' 
for instance:

   say-instead: "as-key";

The drawback with this property is that it has to be applied to a 
specific instance of an element and can't be used more generally. 
In the longer term, the use of pronunciaton lexicons would provide 
a better solution.
</q>

the only problem is that there isn't a dynamic means of switching 
between substituted text and visually rendered text (that is, 
between and acronym and its expansion); it can only be signalled by 
use of a cued sound clip or via CSS' :before and :after 
pseudo-elements.

however, the type of markup provided by CSS3 Speech Module, makes it 
easier for even simple TTS applications, such as a small open source 
screen reader, to obtain information that it might not otherwise be able 
to communicate to the end-user.

gregory.
Received on Friday, 18 May 2007 02:00:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:42 GMT