Re: Screen-reader behaviour

At 12:39 +0100 UTC, on 2007-08-31, Philip Taylor (Webmaster) wrote:

[...]

>  > ATs could read <i> in a slightly different voice. Or just read it normally
>  > and let the surrounding context make clear it's a special term, similar
>  > to what a sighted user of a monochrome display would experience.
>
> Yes, they could.  But the universe of renderings available to
> screen renderers is considerably richer than that available
> to aural renderers, so whilst I might (say) have an introductory
> gloss that says "All ship names appear in blue italics, foreign
> words and phrases in grey italics, Linnaean binomials in red
> italics and book titles in black italics", I would be hard pressed
> to have a similar introduction to the aural version

Maybe (I haven't researched speech possibilities enough to judge). But this
seems to bypass what a user can actually digest. The visual presentation you
suggest here is similar to syntax colouring. And most of us here probably
agree that it takes some getting used to a particular syntax colouring
scheme, and then still it's only an aid; we still also rely on knowledge of
the programming language, we look at the context, etc. So I think the visual
presentation in your example would only be useful to *very* few people.
Probably only the few specialists on the subject at hand, and then still
assuming they are accustomed to that particular visual presentation.

For a wider audience, such presentation can help, but shouldn't be the only
indicator. The (con)text will need to be provide good hints. And once that's
the case, I wonder if the possible variations of aural presentation would
really be too limited.

[...]

> To summarise : the differentiation between a book title, a loan word,
> the name of a ship and a Linnaean binomial /may/ be important in
> some documents, and for those documents, there needs to be a means
> to express the distinction in HTML.

In principle I agree, but in practice I wonder where to draw the line.

I'm inclined to think that @class is 'good enough' for this. UAs can make the
class value available to users (that they don't is just a UA bug IMO). And
authors can provide a legend to their sites, that explain class names.
Authors can suggest a presentation, and users can choose to override that
with user CSS. The latter seems reasonable to me at least in cases where a
site is visited regularly by a user, and the site's author has bothered to
use descriptive class names and to provide a legend explaining them.

Obviously the assumption here is [1] that UAs make it easy for users to write
user CSS (a good UA provides a uuser-friendly UI for that, so that users do
not have to learn CSS), and [2] that UAs allow users to define user CSS to
apply to a specific site/domain/section/page. Another thing that UAs could do
to make users' life easier is to allow the selection of analternate
StyleSheet to be persistent across a site. (Well, AFAIK they don't yet offer
that. Maybe some do?) That would make authoring of alternate Style Sheets
much more worth an author's time.

> This is true no matter at
> which medium the document is targetted : visual, aural, braille,
> or any other.  However, the aural medium has associated difficulties [...]
> --------
> [1] A "mondegreen" is a mis-hearing, usually resulting in comic
>      effect

Wouldn't the best way to convey such a thing be to provide an audio file?
Something like his:

<audio src="ladymondegreen.ogg"><pre>They hae slain the Earl Amurray,
And Lady Mondegreen.</pre></audio>
<pre>They hae slain the Earl of Moray,
And laid him on the green</pre>


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Friday, 31 August 2007 16:03:55 UTC