Re: How CSS is critical for accessibility

to follow up on what Daniel Dardailler said:

> My personal view is that making HTML4 and CSS2 successfull for the
> delivery of flashy or otherwise graphical content is paramount, and
> much more important than making CSS successfull in conveying audio or
> braille output.
> 
> This is really about giving back to HTML its simplest form of just a
> content+structure vehicle (and putting all the presentation glitter in
> SS).
> 

I don't want to try to stop you or the WAI from helping CSS succeed.
I am concerned that the WAI not feel it _must_ ensure the success of the
segregation approach represented by CSS.  This may be a major objective
of the W3C but I see a limited coupling with the accessibility interest
and project.

  - The WAI expertise is not the strongest resource to make CSS a winning
    glitter vehicle

  - Getting the glitter out and getting the content in are largely 
    separable concerns, and what concerns the WAI is getting the content
    in.

My illustrative example for the second idea is italics and
Braille.  In order to do italics right in Braille, you need to
know the reason for the italics.  If all we have in the HTML is
EM, Braille loses, just the same as if all we have is I.  If the
reasons for the italics are given by using informative markup
such as DFN, Braille wins.  The critical difference is "Does the
authoring process get the basis for the italics from the author?"

The encoding difference beween using

  - The element is DFN and the style applies italics
  - the element is <I CLASS="DFN"> and no style is used

is not a grave matter of concern to the Braille formatter than
can win either way.

> Things like ACSS and BrailleCSS are good, but I see them more being
> used a pure client-side features, and therefore, being implementable
> by any client at any time (using whatever means they like, maybe not
> SS at all, like pwWebSpeak of today for instance).
> 

I agree.  

-- Al

Received on Monday, 3 November 1997 13:20:14 UTC