Re: AU guidelines 19990326

Lauren's comments marked LW: Mine marked CMN:

On Fri, 26 Mar 1999, Lauren Wood wrote:

  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".
  
CMN:
I suggest an editorial amendment clarifying the scope of a technique along
the lines proposed.

LW:
  Spell-checking! I noticed "seperate", "accessibile", and others.
CMN:
Woops. I had not spellchecked the final pass document, but it did get done
later.

LW:  
  checkpoint 2.1.2: does "extensions" here apply to
  company-proprietary extensions, or extensions made by other W3C WGs,
  or what? Please specify better.
CMN:
Applies to non-W3C extensions - many authoring tools produce markup based
on a proprietary DTD. I suggest we clarify text as follows:

Ensure that extensions made to W3C specifications (eg in a proprietary
DTD) do not reduce accessibility.

In addition, explanation should be added in the techniques.

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

CMN:
Agree. Any suggestions anyone?

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

CMN:
This checkpoint clearly needs to be worded more carefully

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

CMN:
It means that where no alt text is provided, and a null option is not
explicitly selected, the defualt should be to leave out ALT text - this
will be flagged as an accessibility error. Should be made clearer in the
document.
  
LW:
  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?

CMN:
As used within WAI, User Agent is a reading/browsing tool. An Authoring
Tool is a reading (and often browsing) tool, but which provides further
funtionality. And in some cases the reading/browsing functionality is
extremely limited.

LW:  
  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.

CMN:
Providing programmatic interfaces so that Screen Readers, special purpose
scripts, etc can be used to enhance accessibility is meant to be covered
by 3.1 Should we make it more explicit?

LW:  
  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"?
CMN:
Yes and yes. A bit of editorial cleaning will be done.

LW:  
  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.

CMN:
This is meant to be covered by 3.1 - implementing DOM and an interface to
it is a standard way to provide access to documents. Perhaps we should
make it more explicit. 

The question of native implementation vs requirements for interfaces
hasn't been addressed yet.

LW:  
  3.4.1: define "properties" better
CMN:
I'll link it to the definition

LW:
  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). 
  
CMN:
This could do with clarification.

LW:
  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
CMN:
Lauren, thanks for the comments - lots of food for thought.

The editorial issues will all be worked through preparing the public
draft. I hope the working group can address the other issues in time for
that draft as well - we'll give them our best shot.

Charles  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Monday, 29 March 1999 13:00:32 UTC