W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > January 2001

Re: Comments on AERT (longish)

From: Nick Kew <nick@webthing.com>
Date: Mon, 1 Jan 2001 19:02:08 +0000 (GMT)
To: Al Gilman <asgilman@iamdigex.net>
cc: w3c-wai-er-ig@w3.org
Message-ID: <Pine.BSF.4.21.0101011832320.492-100000@fenris.webthing.com>
> [more orientation to what gets done where among the WAI groups.]

Thanks - I'll get oriented eventually ;-)

> [general comment: the techniques in the document are a mix of automatic,
> automated/interactive, and purely manual techniques.  Your comments sometimes
> err by assuming that only fully automatic checks are under discussion.]

Well, since my main interest in the subject is as a developer of software
and associated tools, I naturally want to focus on what can be done
automatically, or at worst detected automatically and presented to the
author (in the manner of a spellcheck).

> [ re DTDs ]

> [second pass]

> This is a deeper issue than I thought.  The WCAG 1.0 simply assumed that the
> DTDs in the W3C Recommendation were the way to go.  The idea of floating a WAI
> DTD that is stricter than the W3C Recommendation is an interesting technique I
> am not sure we understand the pros and cons of yet.

I'd suggest it encompasses at least two separate techniques, both of
which I am pursuing:

  (1) General-purpose DTDs designed for accessibility and recommended
      to authors.  To be suitable for general-purpose use, such a DTD
      must reflect current practice and browser support.  In other words,
      basically an accessibility review of an existing standard.
      Example: <URL:http://www.htmlhelp.org/design/dtd/>

  (2) Special-purpose DTDs designed to highlight accessibility issues
      as validation errors.  These need not be suitable for general
      authoring.  Example: the enforcement of header hierarchies
      in the ISO/IEC DTD, a DTD that asks for accesskey and tabindex
      in all form inputs, or a DTD fragment that disallows serverside
      imagemaps in order to generate a message suggesting Clientside.

The Page Valet at <URL:http://valet.webthing.com/page/> includes my
first attempt to use this technique in an operational evaluation and
repair tool.

> >----------------------
> >3.5.1 [priority 2] Check document for header nesting
> >
> >Note: The ISO/IEC DTD enforces this strictly.
> >
> AG:: Is that true?  I thought it took a clause that was above and beyond
> _validation to DTD_ to enforce this.

Yes and no.  Yes it does enforce header hierarchy.  No because it uses
a horrible hack with implied <DIV1> ... <DIV6> pseudo-elements, that
makes it hard to use in a repair tool (I haven't figured out a
workaround - but I wouldn't rule it out).

> (chop - lots of interesting comments - thanks)

Nick Kew
Received on Monday, 1 January 2001 14:04:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:31 UTC