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

RE: New Working Draft

From: Charles McCathieNevile <charles@w3.org>
Date: Thu, 11 Mar 1999 19:27:07 -0500 (EST)
To: "B.K. DeLong" <bkdelong@naw.org>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.04.9903111856190.28952-100000@tux.w3.org>
In section 2.1 there are two checkpoints:

1. Use applicable w3c specifications

This is done in part because another activity of WAI is the review of all
W3C recommendations to ensure that they do not compromise, and where
possible improve, accessibility, and in part because the use of an agreed
open standard promotes interoperability, which is generally helpful to
accessibility.

2. Extensions to W3C specifications must not reduce accessibility

The discussion at the face to face meeting considered simply requiring use
of a W3C standard, but rejected it as hampering innovation which may in
fact improve accessibility. There were two examples given at the meeting,
and I propose that we incorporate them as explanatory text for the
guideline:

the first:
Prior to HTML 4.0 becoming a recommendation, LONGDESC could be used in a
DTD which extended HTML 3.2. This is an obvious potential improvement to
accessibility, and should be allowed.
To which I propose we add:
However, given that there is now an applicable W3C specification for
adding a long decription to most kinds of element, the use of a DESCRIBE
attribute in a DTD would contravene 2.1.

The second example was of a more complex extension - framesets. This has
been laid out previously, but my proposed text for inclusion as techniques
is as follows:
In extending a DTD to provide a new functionality, it is important that
the extension does not compromise accessibility of any information or
function provided through that new functionality which would otherwse have
been provided by an existing structure. As an example, introducing the
FRAMESET DTD meant that the content inside the pages of the frameset were
hidden from existing user agents which could not interpret the DTD. The
provision of NOFRAMES allowed alternative access to the material to be
provided in a manner which was consistent with the DTD being extended.

NOTE: In order for an authoring tool to meet the requirements of guideline
2.2 it would have to make use of NOFRAMES to provide that access.

Charles McCN

On Thu, 11 Mar 1999, B.K. DeLong wrote:

  At 03:21 PM 3/11/99 -0800, Charles Oppermann wrote:
  >I agree that the tool should not write out HTML markup that causes
  >accessibility difficulties, but that is a very different issue than writing
  >out markup that isn't part of a W3C recommendation and they should not be
  >tied together.
  
  Then we need to make sure somewhere in the "validation and checking
  section," the authoring tool mentiones that certain elements specific to a
  single browser are not accessible....like BGSOUND.
  --
  B.K. DeLong                  360 Huntington Ave.
  Director                         Suite 140CSC-305
  New England Chapter     Boston, MA 02115
  World Organization        (617) 247-3753
  of Webmasters
  
  http://www.world-webmasters.org
  bkdelong@naw.org
  

--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 Thursday, 11 March 1999 19:27:11 GMT

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