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

Re: Comments on Authoring Tool Accessibility Guidelines 19991026

From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
Date: Wed, 24 Nov 1999 12:06:38 -0800
Message-Id: <4.2.0.58.19991124115910.00c78d70@mail.idyllmtn.com>
To: w3c-wai-au@w3.org
At 11:00 PM 11/23/1999 , Greg Lowney wrote:
>(1) 1.3, "Ensure that the tool generates..." This and similar phrases are
>used similar in several places.

I've always dislike the use of the word "ensure" in our guidelines.

>I don't feel it is made clear whether the
>authoring tool is required to support these in its default configuration, or
>whether this can be a non-default option available on demand. For example,
>if the user *can* generate content that conforms to the WAI-WEBCONTENT
>Priority 1 guidelines, but it does not happen by default, does that mean the
>authoring tool conforms to guideline 1.3? If it was extremely difficult,
>involving manually editing the HTML, does that still count, or is there some
>objective or subjective limit on the inconvenience? This same issue applies
>to several other guidelines, such as 1.2, 2.2, 4.3, etc.

I think this is a valid point to address.  I don't recall if we still
have a "support generation of accessible code and make that the default"
clause?

>(2) 4.3, "Allow the author to preserve markup not recognized by the tool",
>This is currently priority 2 but I might rate it as priority 1 given that we
>don't clearly define the minimum set of elements and attributes that we
>expect any conforming tool to recognize. This means, in theory, that a tool
>could strip out all ALT attributes and all LABEL elements and still qualify
>for A-Level conformance. In effect the current priority rating seems to
>contradict the rating on other guidelines such as 1.2 that say the tool must
>preserve all accessibility information.

I think he's right with this; it should be priority one given that
a poorly written editor can easily destroy the accessibility of a
page when someone other than the author goes to edit it.

>(4) 7.4, "Ensure the editing view allows navigation via the structure" is
>currently priority 1 but I consider it to be more of a priority 2 or 3. Some
>word processors don't provide structured navigation, and I consider that to
>reduce their usability and accessibility but not to make them inaccessible.

What is the reason for the priority one on this?

 >(5) 7.1, "Use all applicable operating system and accessibility standards
>and conventions". I know there has been a lot of discussion of this, so I
>won't comment at length, but I'm curious whether the reference to operating
>system standards means, for example, that an authoring tool running on
>Windows needs to be usable with the keyboard but the same tool running on
>Macintosh does not. Or, on the other hand, does the reference to
>accessibility standards mean that a tool running on the Macintosh needs to
>provide better keyboard access than is commonly found on that platform?

I don't know if there's any good way to write "what we mean" by 7.1. :-p

-- 
Kynn Bartlett                                    mailto:kynn@hwg.org
President, HTML Writers Guild                    http://www.hwg.org/
AWARE Center Director                          http://aware.hwg.org/
Received on Wednesday, 24 November 1999 15:12:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:22 UTC