Re: Aural Cascading Style Sheets

On Jan 10,  3:45pm, Aymeric Poulain Maubant wrote:

> Håkon wrote:
> > HTML is device independent and there is no need to integrate aural
> > presentation into HTML. [...]

> I really do know what is HTML, SGML and CSS1 :-) ...

I know you do. (For people on the list who haven't mey Aymeric before,
he translated a tutorial on HTML, CSS and HTTP which I wrote in 1995
into French.

( See http://webbo.enst-bretagne.fr/ActiveWebFr/index.fr.html )

> take <img src="..." alt="..."> ; ALT was created for users who *do
> not have* bitmap-oriented browsers (namely lynx).

Yes, and I agree that it can be seen as a presentational hint for
text-only browsers. It can alternatively be seen as adding semantic
markup to an inline image. So for example an image of some nice
typography that gives the main heading of a page could have alt text
describing what the (pictures of words) actually say.

> When reading ACCS, I found 1/ that Chris seems to suggest that some
> stuff addressed in ACCS (like speak-date) should not be in fact in
> the CSS,

Right, I said it should be in HTML. By that I meant that it was semantic
information, independent of presentation. It might also be used by
indexing or search engines for example.

I recall that mark-up for dates and times was in an early draft of the
Internationalisation internet draft, but that also included markup for
currency and valid concerns about the timeliness of automatic curency
conversion resulted in the baby being thrown out with the bathwater ;-)

> and 2/ that speak-punctuation does not address the problem
> of punctuation having a semantic meaning ("[ choice1 | choice2 ]" for
> instance).

This particular example can be addressed in CCS1 by making LI
inline instead of list items. But in general I agree that HTML is not
especially good at capturing semantics, and also that this lack is more
noticeable when using speech rendering. For example, grouping by 2D
positioning conveys relationship well to the sighted reader, but does
not help someone who is listening to a 1D spoken rendition:

    1A         1B  -- 1C      1D  1E

    2A         2B  -- 2C      2D  2E

You can clearly see that 1D and 2D are somehow related, but you cannot
clearly hear it. Another example - you can clearly see this


as twenty five thousand, three hundred and seventy dollars. And this


as 25 French francs and 27 centimes ;-) since many European countries
use comma as a decimal separator and period as a thousands separator.

There are many other examples. The upshot is that, in addition to
describing aural presentation (in the stylesheet) it may be necessary
to add semantic mark-up (in the HTML) whose lack was upt to now not
apparent to most of us.

> Thus I thought that an attribute for span might be
> useful :

> <span altread="Here is a menu">[ choice1 | choice2]</span>

I would suggest instead this sort of construct

<p class=menu><a class=menuitem href=foo>choice 1</a>
<span id=001>|</span>
<a class=menuitem href=bar>choice 2</a></p>

with this stylesheet fragment

.menu     { cue-before: url(menualert.au) }
.menuitem { cue-before: url(choice.au) }
#001      { display: none }

> If we do not want to put such a functionnality into HTML (which is
> sensible as well), I do not see how to put it in the speack punctuation
> property. The following could be an idea :
> speak-punctuation
> value: code | altread | none
> initial: none
> Applies to: all elements but altread which applies only for span
> inherited: yes /* but what does mean inherited for altread which applies
> 		only for SPAN ? */

Yes, you see the problem.

In general, experience with alternative forms (be they alt, noframes,
or whatever) is that they are too hard to keep in sync with changes
to (what the authors see as) the 'main' version. People simply don't
use them.

I have seen some examples of Web pages that appear to have an aural
stylesheet -- they were linked from Apple's macintalk page,
http://speech.apple.com/ -- but these actually used a plug-in which
downloaded a text version of the page )or, part of the page) with embedded
control codes for a particular speech synthesizer. Not very portable,
not very maintainable.

I feel that ACSS provides a superior approach where the actual HTML is
used as the basis for rendering the speech and the browser generates the
requisite control codes for whatever system the reader is using, based
on the stylesheet.

It is better to design mark-up which can automatically be presented in
different ways. The advantage of stylesheets in general, and of CSS in
particular, is that presentation can be defined which the original document
author did not think of. If the author did not design with any aural
capabilities in mind, the readers default stylesheet can still be used to
generate a reasonable rendition.

> UA are encouraged to guess the special meaning (this
> is out of the scope of ACSS specification) : "|" could be spoken "or", for
> instance, "[foobar]" could be spoken "foobar is a bibliographic entry".

In general, we have found that sentences like this give no end of trouble to
developers who would prefer the spec to tell them exactly what to do.

The speak-date property should ideally be rarely used, and ideally should
be used in the dfault stylesheet like this:

date { speak-date: dmy }

or whatever. That would require an explicit date element in HTML. In the
meantime of course,

.date { speak-date: dmy }

will have to do.

> Am I the only one to think there is something missing in the property
> speak-punctuation ?

No. The original impetus was for stylesheets that speak actual code
fragments, like C or Java code examples, that sort of thing. The
problem comes when punctuation is used to give semantics, like this

 - a list item
 - another one

At least HTML solves that one, which is still very common in plain text.

Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France