Re: Section 3 +

This is a pretty good point, and maybe we need to re-examine the problem.

The need is for the user to know the structural role of something. In
visually oriented systems this information was implied by visual
formatting conventions, section numbering, font styles. In non-visual
systems this was implied by markup.

To translate from markup to visual presentation has been understood for a
long time - it is what style sheets do. To go the other way is done by
people all the time, but unfortunately not by software very often. 

So what is needed is access to the properties of an element or part of an
element. In the case of structured documents these will include the
structural function of the element - whether it is plain text, a heading,
etc. In the case of documents which are visually (or aurally) formatted
but not structurally marked up, these will be style properties.

In order to generate HTML documents which conform to WCAG it is necessary
to provide structural markup, which may be generated heuristically as
described in the technique I proposed today. In order to provide
structured markup it is probably sufficient simply to provide access to
the propreties and a means to search for elements based on their
properties. However authors should be encouraged to create structured, and
therefore more accessible documents, where this is not provided by the
sort of autmagical under-the-hood conversion I have described.

Charles McCathieNevile

On Tue, 23 Mar 1999, Bruce Roberts/CAM/Lotus wrote:
  
       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
  
  
  
  

--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 15:58:54 UTC