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

Re: New Working Draft

From: Daniel Dardailler <danield@w3.org>
Date: Fri, 12 Mar 1999 11:19:49 +0100
Message-Id: <199903121019.LAA14028@www47.inria.fr>
To: Charles Oppermann <chuckop@microsoft.com>
cc: w3c-wai-au@w3.org

> I think we should add that having the tool generate non standard
> markup should be cleary indicated to the author. In the same
> checkpoint is fine with me, like "Extensions to W3C specifications
> should be clearly indicated and must not reduce accessibility."
> >>
> Strongly disagree.  What should happen if the tool writes out <BGSOUND>.
> That is somehow wrong?

BGSOUND may be a bad example as it directly related to accessibility:
it's media-specific and would need a way to attach some text
equivalent (a title, a caption, depending).  So without such a
mechanism (which I'm not aware it has or hasn't), it would fall under:
extension which must not reduce accessibility.

Now consider the case of an extension that just adds some new
semantics markup in the document, say a way of creating a multi-target
link thru an additional A attribute: <A href="urld" mhref="url1, ul2, url3">.

If this is done without alerting the user that this is non-standard,
then the user will not know that X% of the web population will not
access this feature they just spend time to put in.

This is wrong because when you author on the web, you always think you 
author for the web at large.

This is an accessibility problem because specialized accessilibity
user agent are always the last ones to get up to speed with the latest
gizmo/extensions, and usually they can only trust standards.
> 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.

I think you're right, it actually falls under 2.1.1:

  2.1.1:  Use applicable W3C specifications. Alert the author
          when extensions are generated by the tools. 

 (and keep 2.1.2 to bannish innaccessible extension)

The alerting for extensions would fall under the configurable set of
course: as an author, I should decide if I want to know whenever the
authoting tool is going to generate BrowserA or B extensions, or if I
don't care.
Received on Friday, 12 March 1999 05:20:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC