W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

Re: New Working Draft

From: Charles McCathieNevile <charles@w3.org>
Date: Fri, 30 Apr 1999 23:19:24 -0400 (EDT)
To: William Loughborough <love26@gorge.net>
cc: au <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.10.9904302246320.5176-100000@tux.w3.org>
On Fri, 30 Apr 1999, William Loughborough wrote:

  Section 2 intro: Still think should say "content, structure, and
  presentation" instead of allowing "content" to include all that.  Note
  that the first bullet says: "Separate structure and content from
  presentation;" and later "...higher level problems of overall design,
  content, description, etc."
  In short, if one does a search on "content" and determines if it is used
  as defined in WCAG definition section leave it alone, otherwise expand
  to "content, structure, and presentation" as this will emphasize the
  point made in the aforementioned bullet.  In this posting I will make no
  further reference to instances of "content" in the document, but there
  are more.

I agree. We have not done that for this working draft, but I will do it for
the draft we will be working on in Toronto.

  2.3 "...assist the author in generating textual equivalents..." I wonder
  if we might again spell out the other equivalents like audio or
I think it would just add bloat to the paragraph myself. We now mention
various types of multimedia in techniques.

I suggest in 2.3.1 (prompting for alternative content) we suggest some stuff
for adding alternative content to multimedia, and think about how to deal
with multimedia where it is alreday included, such as SMIL presentations. My
personal feeling is that tools which do not understand SMIL (mostly
HTML things - XML tools should generally be able to deal with SMIL itself) 
should still be providing alternative content for a SMIL presentation.

  2.5.2 Grammar checker should examine this; it's the markup that is known
  to promote accessibility and the sentence might mean that the tool does
I don't think it is a big worry, but we could leave out "supported by the
tool", since it is an obvious precondition from 2.5.1

  2.5.3 And wherever else should end with a "." since the others do; also
  I think all bullets end with ";"?
I'll put the period into the source on Monday, for future versions. Bullets
end with semicolons where they are lists of things, except for the last one
in the list. For techniques, which are listed, they should all be sentences
and therefore end with a period.

  2.6.1 I think we "alert to" not "alert of"?

I usually do - duly noted...

  3 "Ensure that the Authoring Tool is Accessible to Authors with
  Disabilities"  I guess I still think this should be "All Authors"
  instead of "authors with disabilities".  The old Universal Design
  argument. Further on: "...accessible to authors with disabilities" might
  be "accessible to authors of varying skills, styles, and abilities".

I agree. Actually I think that language was in what is now the checking and
assisting guidelines - 2.6

  Then "2.The authoring tool frequently encompasses the functionality of a
  user agent or browser and as such should follow the User Agent
  Accessibility Guidelines. [WAI-USERAGENT]" should make it clearer that
  this refers specifically (exclusively?) to those functions of the
  authoring tool that mimic a user agent which is made clearer in 3.1.2
  than in the introduction.  

I think given that it is explicit in the checkpoint we don't need to harp on
it in the introduction

  Perhaps we could use a checkpoint 3.2.3 of
  priority 3 that provides a display of the document in its full anatomy
  such as one sees in a browser's "view source document".  Some tools make
  this hard to get to.

I will take this as a proposal for a checkpoint. (At any rate, it is a
technique which can be used to satisfy other stuff - for example the
structure View in Amaya makes it trivial to navigate element by element
(3.3.1 minimally satisfied...)
  3.3 "...There are strategies that make it easier to navigate and
  manipulate a marked up document" cries out for a link to such
Sounds like a technique to me...

  A general formatting recommendation: There should be a blank line
  between the end of a technique and the presentation of the next
  checkpoint; in the present format it looks like the technique belongs to
  the subsequent, rather than the previous checkpoint.
Good thought. I'll follow it up with the Style gurus (Ian). Maybe we should
say "Techniques for x.y.z"?

  I've not gone into the techniques, appendices, etc.
What?!?! An hour and a bit and you haven't surveyed every last detail? (Just
joking. Thanks for the comments and thoughts, and the prompt review. It's
always gratifying to know people are waiting for the thing to "come off the
press" as it were.)

Received on Friday, 30 April 1999 23:19:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC