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

Re: Section 3 +

From: Bruce Roberts/CAM/Lotus <Bruce_Roberts/CAM/Lotus@lotus.com>
Date: Tue, 23 Mar 1999 18:29:29 GMT
To: w3c-wai-au@w3.org
Cc: Charles McCathieNevile <charles@w3.org>
Message-ID: <OF15798D96.0FC87A87-ON8525673D.0062671A@lotus.com>

     My understanding of the spirit and letter of section 3 conflicts with
what you're proposing.  Based on the last tele-conference and the current
working draft, section 3 should only give guidelines that relate to the
"unique functionality of authoring tools".  If we open this up, I fear
we'll end up sliding down a slippery slope.  While I'm not crazy about
guideline #3 as I've stated previously, I can live with it if we keep it in
this restricted sense.

     There is an Editor's Note for guideline #3 stating that the
introduction will be re-written to highlight some of the main points
provided by the other standards documents.  Maybe your checkpoints could go
there.

     Also, as we phrase the guidelines for this section I'd like us to keep
in mind that web site creation tools are not the only authoring
tools...Office/Suite applications (Word Processors, Spreadsheets,
Presentation Graphics, etc.) are more and more used as web authoring tools
so any guidelines should be worded appropriately for them as well.  For
example, guideline #3.3.1 ("Allow the author to display start and end tags
in a text format") doesn't make sense for Office/Suite apps.  We could
qualify it:  "For authoring tools that support display of tags for markup,
...".

-- Bruce





Charles McCathieNevile <charles@w3.org>@w3.org on 03/23/99 12:17:57 PM

Sent by:  w3c-wai-au-request@w3.org


To:   William Loughborough <love26@gorge.net>
cc:   "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>

Subject:  Re: Section 3 +


I think we want a guideline that says 'implement accessibility features
for the platform' or something like that. Although we don't want to repeat
the work which exists, there are a few things we ought to point out.

The primary requirement is that standard operating system conventions are
followed. This seems like a P1 checkpoint if we accept such a guideline,
and we should, in techniques, refer to various documents which exist for
different platforms.

In particular, user configurability of input device(s) and output devices,
and the implementation of standard program interfaces to allow assistive
technologies to be used. I imagine that these issues are covered in the
average set of standard processes, but they are sufficiently basic that I
would like to see them abstracted as checkpoints.

This has particular relevance for determination of conformance. As Rob
Cumming and others have pointed out, a method to measure conformance is
likely to be crucial for the adoption of these guidelines. As Jutta has
pointed out, it is crucial to make it clear that the platform-specific
guidelines must be met, which is why I have suggested that as the first
checkpoint. These other requirements are crucial. They ought to be met by
fulfilling the first requirement, to implement standard systems, but in
cases where that does not happen they must still be met.

So I am working on a proposal which will look something like the
following:

Guideline 3.X Ensure that the tool is an accessible piece of software

rationale: Tools need to implement standard accessibility features for the
platform they are on, so that assistive technologies can be used.

checkpoints:
3.x.1 Implement the tool using standard operating system conventions and
accessibility conventions [p1]

techniques: see the various documents we can think of (I can think of four
off the top of my head)

3.x.2 Ensure that user input devices can be configured

techniques: In most cases this is satisfied either by 3.x.1. In systems
where this is not true, but where it is possible to reconfigure the
keyboard, which applies in many systems, providing complete keyboard
control will satisfy the checkpoint.

3.x.3 Ensure that output devices are configurable

techniques: I'm not sure exactly. Which is one of the reasons this isn't a
proposal yet, just the outline of one (grin). An example is that in an
environment where audio and visual output is generally available, it is
possible to specify that no audio output should be used, and anything
which defaults to audio output (eg a warning beep) should be rendered
visually.

3.x.4 Implement standard program interfaces

techniques: implement relevant w3c DOM specs. provide hooks for controls,
so assistive technologies can interface with the program. (implement 3.x.1
for some good system where these things are well organised)

any thoughts on this?

charles



On Tue, 23 Mar 1999, William Loughborough wrote:

  Because the Web is still so largely inaccessible, even to people like
  Tom Fowle of Smith-Kettlewell I asked him to read the guidelines and
  report if there was any renewed hope that he'd become a Webber:

  TF: I've read through the content and authoring tools guidelines:
  About the only thing that seems missing to me is any mention that
  authoring tools must conform with the needs of screen readers or other
  access systems on the platform for which they are intended.  E.G.
  in winderz, MS active accessibility as only a basic start.

  TF: It might be there I just didn't hear it.

  WL:: I think the aspect of section 3 that might cover this is that if
  the tool is designed to run on "X" then the tool should be eminently
  accessible via screen reader, brl, or whatever???
  --
  Love.
              ACCESSIBILITY IS RIGHT - NOT PRIVILEGE
  http://dicomp.pair.com


--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 Tuesday, 23 March 1999 13:24:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT