RE: CSS accessibility problems: is markup dead?

Danny Ayers:

> A good piece - your have a reasonable point and argue it well. On the
> downside I would say that it only gives part of the story.

I think this impression might be mainly caused by the subtitle-like text
"Top ten accessibility problems created by use and misuse of CSS", which now
appears in the "breadcrumbs" and pointing to
http://www.mcu.org.uk/articles/cssaccessproblems
which points (via redirection) to the page itself. Reflexive links (i.e., a
link that points to the page itself) are confusing, and using different URLs
adds to the confusion, since a browser initially treats it as unvisited link
(since the _URL_ has not been visited). Maybe it's intended to become a
structural link that points to a page with links to nine other articles?

But despite such problems, and other (minor) problems in the accessibility
of the page itself, like using alt="Decorative photo: white flowers."
instead of alt="" title="Decorative photo: white flowers.", I found the page
very good, too. I'm biased, in a sense, since I've presented similar points
for years, e.g. in my article "Lurching Toward Babel: HTML, CSS, and XML" in
"Computer" in July 1998,
http://computer.org/computer/co1998/pdf/r7103.pdf
(Yes, in PDF format! Not my choice.)
 
> You make the point that using e.g. <SPAN> rather than <H1> for things that

> are headers is lacking something, though you don't actually pin down what
it 
> is.

I think the article presents that fairly well - it points out that <SPAN>
lacks a defined meaning that could be adequately processed by programs, such
as indexing robots, speech synthesis, browsers applying user style sheets,
etc. And let's not forget browsers with CSS turned off (or not supported at
all). What does <SPAN> degrade to? Nothing. There's no reason why <SPAN>
markup per se should be processed in any particular way.

For example, when headings are adequately marked up, a browser that
generates speech can pause before a heading, read it slowly, pause, and
continue its normal (fast) speed. This makes the document _much_ clearer and
easier to listen; it is comparable to using spacing and large fonts in
visual presentation. A browser could not, and should not, do anything like
that with <SPAN>, even if the tag has class="otsikko" or class="rubrik" (or
even class="heading" - it would be quite unappropriate for a browser to make
guesses based on what some string might mean in some particular natural
language).

Sure, you could write an aural style sheet for some <SPAN>s. Even in
principle, it would solve just small part of the problem. In practice, when
did you last see a browser supporting aural style sheets? Besides, trying to
cover _all_ the possible presentation environments by writing style sheets
for them is an endless task. Some browsers use one font only but variation
in font color to indicate major structural ingredients like headings. They
do it automatically, as long as you use appropriate markup; but you can't
make them do that for your <SPAN>s.

> IMHO, I'd say that thing was metadata

In a sense, all markup is metadata, data about data. But I don't think this
view is particularly useful. What we normally call metadata in the WWW
context is data about such data that consists of entire documents like an
HTML document and associated images etc., i.e. "Web pages".

> Another way may be to use named
> classes, like "tophead" in your example, though of course it 
> would be better if they came from well-known vocabularies - class="h1" 
> perhaps?

No, class="h1" does not mean anything more (to a browser) than class="foo".
The class name is just an assigned symbol with no intrinsic meaning. Things
might change if we defined some specific rules for class names, with
semantic definitions (e.g., "h1" means 'first level heading') and published
them and got wide acceptance. Then we would have reinvented the wheel,
wouldn't we? It would be just like HTML, except more clumsy.

> Hopefully - - we won't need to rely on a vocabulary of maybe
> two dozen terms plus fairly arbitrary nesting rules to explain
> our document's structure 

It was one of the basic weaknesses of HTML as originally defined that it had
only a handful of markup elements you can use. But it was also one of its
fundamental strengths. The smaller the set of markup elements that a program
_must_ recognize and process in some particular way, the easier it is to
write programs that process marked-up data, for visible or audible
presentation or for other purposes. (Actually, a qualified programmer could
write a browser for HTML 2.0 in an hour, a _different_ browser that has some
special treatment for markup like headings, to suit the properties of some
new device, or the needs of some particular people.) And the ease of
creating "different" user agents is essential to accessibility.

-- 
Jukka Korpela
TIEKE Tietoyhteiskunnan kehittämiskeskus ry
Finnish Information Society Development Centre 
Salomonkatu 17 A, 10th floor, FIN - 00100 HELSINKI, FINLAND
Phone: +358 9 4763 0397 Fax: +358 9 4763 0399 
http://www.tieke.fi  jukka.korpela@tieke.fi

Received on Thursday, 16 May 2002 03:10:01 UTC