[Irl-dean] Opinions: HTML Transitional and WCAG Double-A

[Barry McMullin]

On Tue, 9 Jan 2007, Gez Lemon wrote:

> The only element that is still widely used in the transitional DTD
> that isn't in the strict DTD is APPLET, but that can be implemented
> using OBJECT. There are lots of deprecated elements, such as DIR,
> MENU, FONT, etc., but these are not so common, and fail other
> checkpoints (such as 3.3: use style sheets to control layout and
> presentation, and 3.6: mark up lists and list items properly). Most of
> the attributes that have been deprecated either belong to deprecated
> elements (such as alt for applet), or are presentational (align,
> valign, bgcolor, etc.). The only exceptions to this are language
> (script), start (ol), value (li), and version (html).

Thanks Gez - that's very helpful.

So, by my reckoning, we are left with the following candidate
features of transitional doctypes that are not available in
strict doctypes, but arguably do not intrinsically imply WCAG 1.0
violations:

Elements: The only one seems to be APPLET; and even this is still
a candidate only due to historically problematic browser support
for OBJECT (which is a more powerful and general purpose
facility, in general). Browsers have moved on, and support for
OBJECT has now improved; but I guess one might still accept
APPLET as a reasonable justfication for choice of a transitional
doctype. (Actually, EMBED is probably more of a practical issue
here, rather than APPLET; but, of course, for better or worse,
EMBED is not recognised even in the transitional doctypes, so
that would really be a quite separate discussion!)

Attributes:

- target (on A element): specifically in the context of
  suggesting opening a new window. We all agree (?) that opening
  new windows is not *generally* a great idea; but sometimes it
  does make reasonable sense, and, in that situation, it may be
  reasonable to stick with a transitional doctype; though even
  then, using javascript (with strict HTML) might be a better
  choice in general.

- language (on SCRIPT element): but the "type" attribute does a
  better job and is supported by all (?)  widely deployed user
  agents (at least where it is relevant - i.e., where the user
  agent supports the SCRIPT element). So "language" should
  presumably be regarded as technically violating WCAG 11.2
  ("Avoid deprecated features of W3C technologies"). This
  "violation" would have little if any practical effect (?), but
  since it is trivial to correct, there is no good reason for
  leaving it in place.

- version (on HTML element): ditto - doctype does a better
  job and is supported by all (?)  widely deployed user agents,
  so "version" should presumably be regarded as technically
  violating WCAG 11.2. Again, this has negligable practical
  effect (?), but since it is trivially corrected, it might as
  well be so.

- start (on OL) and value (on LI): both are concerned with
  fine-tuning the automatic numbering of "ordered" lists.  The
  reason they are deprecated is, presumably, because this
  functionality is considered to be primarily "presentational"
  and is therefore better delegated to the stylesheet language
  rather than embedded in the HTML; and, indeed, CSS 2 defines
  support for this. On that basis, one might argue that
  continuing to use start and value are specific violations of
  WCAG 3.3 ("Use style sheets to control layout and
  presentation").  This is not an entirely idle point: separating
  this into the stylesheet *might*, in principle at least, make
  it easier for presentation or rendering of the numbering to be
  tailored to suit the particular needs of users.  On the other
  hand ... support for these CSS features has historically been
  fairly "mixed" (though I'm not sure of the up to date situation
  here); and, in a "practical" sense, I am not sure whether any
  browser or AT available *today* would actually show any
  additional, useful, functionality by virtue of shifting this
  into a stylesheet. So, on balance, if an author today was
  continuing to use a transitional doctype, specifically in order
  to use the "start" and "value" attributes, I would probably
  accept that; though if and when browser support for the CSS 2
  alternative stabilises, then I would probably recommend
  switching to this as a "best practice" (in deference to
  WCAG 11.2, and to facilitate specialist UA developers to start
  taking advantage of it).


Thanks again to all who responded on this. My own conclusion is
that, with *very* few exceptions, which we have now fairly well
exhausted (?), developers or site owners should *not* claim WCAG
Double-A conformance for resources using a transitional doctype.
Yes, it's only a rule of thumb, but I think it may a useful one,
just at the current stage of development.

In particular, this highlights to me at least, that shifting from
HTML transitional to HTML strict *potentially* has rather more
significance for accessibility than, say, shifting from HTML
transitional to XHTML transitional ...  (I only say "potentially"
because it is, of course, technically possible to effectively
"emulate" most of the "bad" aspects of HTML transitional in HTML
strict, simply by promiscuous use of the style attribute; so a
meaningful shift from transitional to strict has to involve
actually engaging with the *spirit* of properly separating
content and presentation, and not just the technical "letter" of
using a strict doctype ...)

Best regards,

- Barry.