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