Guidelines - 4 nov draft

I realise that some of these comments may be out of date. They are also 
very terse. This is partially because it is late at night and I have a 
lot to do tonight, and partially because I would rather expand on them as 
necessary and forget them where they are no longer relevant. If anyone 
finds this approach diffiuclt to deal with (I know some people do) please 
email me and I will try to make fuller comments from the beginning in future.

Charles McCathieNevile

Comments are marked by section, or by technique number, reading 
sequentially through the document.


1.1 the first of the two parts could be changed to 'Guidelines for 
development of web authoring tools which produce material that is accessible'

2.1 Definition of Authoring tool:
An authoring tool is a piece of software which assists the user to 
produce documents in a particular markup or presentation language. This 
includes tools which provide automated code insertion while editing an 
HTML document (for example) as well as tools which hide the HTML document 
being produced, and allow the user to edit a rendered version of the 
document. It does not include text editors which are used to 'hand-code' 
documents.

Conversion tool:
change 'this includes dedicated web publishers as well as' to 'this 
includes software whose primary function is to convert documents to a 
particular markup language as well as...'. The definition as it stands 
provides some confusion - it is possible to read it as saying that 
PageMill (a dedicated web publishing package) is a conversion tool, when 
it is an authoring tool. (I assume that's right. I may be the one who's 
confused of course).

Image editor:
I agree with Daniel. I think that anything used to work on an image is an 
image editor. Simplifying this would remove possible grounds for 
confusion, which does not actually serve any purpose

2.7
We should define insertion point and its relationship(s) to focus and 
selection.

Technique 3.1.2.5 Tools should not publish inaccessible pages.

Unfortunately I think I have to disagree - the tools are never going to 
know better than a good human whether a page is inaccessible, and may in 
fact end up blocking the publishiing of accesible material because they 
don't understand. This would seriously undermine acceptance of our work. 
(I for one would throw out a tool that didn't let me do what I wanted - 
I preferred to use an old version of MS word than work out how to stop 
the new one from playing around with my HTML)

Technique 3.1.5.2
the author should be given the option of providing long description for 
any (remove) graphic element (add) element which can have a description 
associated.

Add to section 3.1.5 a new technique:
THe author should be prompted to provide content for any element which 
can use it to improve accessibility - for HTML this includes NOFRAMES, 
OBJECT, APPLET and IFRAME

3.1.6

Is there an image format which contains within the object a text 
description? This would be useful, if we could promote its use and get 
UAs to accept it. Although it is only a long-term strategy.

Technique 3.2.4.1 Provide professionoally written descriptive text for 
prepackaged multimedia material...
I assume that this applies to material for a LONGDESC - ALT is probably 
too variable, since it is function based, except for such horrible things 
as pictures of words, which we should be recommending against anyway.

Techniques 3.3.2.1 and 3.3.2.2
These should be collapsed into a single technique - the second one is 
merely an adverbial clause describing the manner in which the first 
should be implemented (not to put it in laymans' terms)

Technique 3.3.5.1
Authoring tools should never remove or modify structure or content 
(remove) that is necessary for accessibility (add) without asking the 
author first.

See my comments on publishing 'inaccessible' material.

Techiniques 3.3.5.2 and 3.3.5.3

Put 'but' in between these and make them one technique

technique 3.3.5.8
Authors should be given the opition of displaying the site map in text 
form ((insert) for example (/insert) as a structured tree file)
This should also be a technique for site management tools in section 3.

5.1 definitions of Alert techniques should be in definitions section. 
Since we are pitching at developers we should expect them to be able to 
read the definitions where necessary.

And can we move the definitions to the end of the document, so it gets 
into the business a little quicker?

Received on Wednesday, 11 November 1998 06:36:28 UTC