- 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
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 UTC