W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 1998

Re: white book on accessibility

From: Daniel Dardailler <danield@w3.org>
Date: Fri, 11 Sep 1998 17:35:35 +0200
Message-Id: <199809111535.RAA20711@www47.inria.fr>
To: Dominique.Archambault@wanadoo.fr
cc: Liste WAI EO <w3c-wai-eo@w3.org>, Dominique Burger <Dominique.Burger@snv.jussieu.fr>

Dominique, some comments on

> http://calypso.cher.univ-lehavre.fr/~arch/livreblanc/wb.html

> Conception of Web pages
> White Book about accessibility (first draft)

What does "White Book" means ?

Is this like a White Paper ?

I like the Introduction a lot.
> 1.2 HTML 4.0
> The HTML norm provides all required tools to write an accessible code. The
> advantage of HTML is not only that it enables to create a multimedia and
> hypertext layout of page. 

HTML is for structural and semantic, CSS is for layout.

Maybe you can just say HTML and CSS whenever you say HTML.

> The DIV element allows specifying the function of a paragraph (for
> example a navigation bar).

Not really the purpose of DIV, but I guess that's fine for this

> longdesc attribute. As long as the browsers do not support this new
> function, a description link can be placed next to the image (only with the
> text "D" and ALT "dlink")

ALT dlink on which element ? not the IMG since it has its own alt ?
You mean when Dlink is itself an image. Unclear.

> The object element can also be used (today's
> browsers have not yet properly recognised neither the longdesc attribute nor
> the object element, which have appeared in the latest W3C recommendations,
> but this situation should not last. Consequently, the most efficient
> technique is - for the time being - to use the descriptive links).

No need for complicating the picture...

> 3. Use of HTML editors
> The use of HTML editors often causes problems. The safest way to make a
> document accessible is certainly to type directly in HTML. However, some
> other tools can also be used.

This is one important aspect that I think we ought to mention
somewhere on the business card or on any short version we produce in

> Tools to rule out are those which destroy all your adaptations for
> accessibility at each saving and which rewrite on their own way all HTML
> elements. Tools that do not allow the HTML code to be directly edited should
> also be avoided. In fact, these are all the tools that do not permit you any
> control on the HTML code you are writing (Microsoft Word 97, Netscape
> Communicator...). In such cases it is necessary to use a text editor to
> correct the code (this stage is boring since this code is automatically
> generated without any control and it is rarely clear!).
> There are other tools which seem to be better adapted. Tools like Corel
> WebMaster, HotMetal (SoftQuad), DreamWeaver (Macromedia) allow an easy
> realisation of accessible sites. There are contradictory opinions about
> FrontPage (Microsoft). Users note that many accessible sites were created
> with FrontPage. In addition, it was blamed for nothing precise. Therefore,
> it may be possible to use it for the work with some care.

It's delicate to start reviewing tools in such a paper.

But we still have to decide how to use it anyway...
> Two other simple tests consist in visualising the pages in black and white
> (simply in changing the screen settings) and testing them without displaying
> images, scripts or applets (simply in changing the browser settings).

Also mention lynxit service.

On a side note, I'd like to know how much of your text we can reuse in
other articles/papers.
Received on Friday, 11 September 1998 11:35:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:29:27 UTC