AU guidelines 19990326

I will start by admitting that I haven't been following the mailing
list for some time, which means I'm reading this from a fresh
perspective of someone who has implemented some accessibility
features in an authoring tool already.

I think the present draft has come a long way from a previous
version that I read some time ago. I still have a few comments
though.  

Definition of Technique: the DOM is not a language; perhaps this
could be written as "an implementation ... in a given way" or "using
particular methods".

Spell-checking! I noticed "seperate", "accessibile", and others.

checkpoint 2.1.2: does "extensions" here apply to
company-proprietary extensions, or extensions made by other W3C WGs,
or what? Please specify better.

checkpoint 2.2.3: define what you mean by "templates" here - there
are so many meanings.

2.3.5: I think there's a "not" missing before the "known with
certainty".

Techniques in 2.3: what does "Default to an accessibility error such
as no 'alt' attribute for images" mean????

2.7.4 is graded as priority 3 - I think explaining universal
benefits is going to be the best way of getting people to actually
write accessible pages. Otherwise the temptation is to simply turn
off those pesky dialog boxes and not bother. So maybe a priority 2?

Chapter 3: I always thought that authoring tools were encompassed
under the phrase "user agent". Is that not true? If not, what is the
actual definition of a user agent, and which bits of it exclude
authoring tools?

I would also suggest something else that can be added to this
section: an authoring tool that works with 3rd-party tools that make
the authoring tool accessible. For example, an authoring tool that
can be used with a speech reader, or an authoring tool that supports
scripting so that add-ons to help accessibility of the tool can be
written. This is more applicable to section 3.3 and 3.4 than 3.1 or
3.2, of course.

Guideline 3.2: the first sentence doesn't make sense to me. It helps
if I delete the word "it" after "wish", but it's still unclear.

3.2.1: should the first "of" be "is"?

3.3: This is where APIs such as the DOM come in. When used
internally to an authoring tool, the DOM can enable the writing of
separate applications that use that DOM interface to get the
information from the document and pass it to the author. Then the
author can pass information back about what they want to do to the
authoring tool via the DOM. 

3.4: Similarly here, an authoring tool that supports the DOM can
represent elements graphically and still give an author a way of
translating the content to Braille etc. 

So for 3.3 and 3.4 it's important that the authoring tool make this
possible, but the authoring tool doesn't need to implement
everything itself, if it supports some way of adding the necessary
functionality. I admit this means that people needing the
accessibility features will then often need to do some programming,
or find 3rd-party add-ons that work, but this system would also be
more flexible to particular needs of different groups.

3.4.1: define "properties" better
3.4.2: site maps? What site maps? Shouldn't this say "if extra
information, such as site maps, is available, there must be a way to
get this in text form"? (Or similar; again, the authoring tool
doesn't have to do the text representation itself if it can make
that information available, IMO). 

I hope this helps and isn't rehashing old issues. If so, I'll
understand if you ignore every word I've written (apart from fixing
those spelling mistakes....)

regards,

Lauren

Received on Friday, 26 March 1999 21:56:01 UTC