W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2000

Politics: Strict Guidelines Considered Harmful

From: Kynn Bartlett <kynn@idyllmtn.com>
Date: Thu, 14 Dec 2000 18:16:21 -0800
Message-Id: <a05010415b65f26b1c259@[10.0.1.2]>
To: "Charles F. Munat" <chas@munat.com>, <w3c-wai-ig@w3.org>
Note subject change; also, there is a disclaimer at the very end of
this.

At 5:34 PM -0800 12/14/00, Charles F. Munat wrote:
>But that's all beside the point. Let's go to the actual text of WCAG 1.0:
>"3.3 Use style sheets to control layout and presentation. [Priority 2] For
>example, use the CSS 'font' property instead of the HTML FONT element to
>control font styles."
>How can you say that 3.3 does not prohibit the use of font tags for control
>of font styles when that is the very example given in the standard?

Because of the larger principle of "let all votes count".  Wait, that's
not what i meant to say.  It's because of the larger principle of
"do not introduce accessibility barriers."

The following two bits of markup have, I maintain, the same effect
on the accessibility of the content:

<span style="font: Arial"><font face="Arial">Text</font></span>

<span style="font: Arial">Text</span>

Anyone who would argue that the latter is -more accessible- and
-removes an accessibility barrier- is simply incorrect and too hung
up on tag-level dogma than on true human accessibility.

(In fact, the first bit of markup works in Netscape 3, while the
second one does not.)

>Now,
>whether that's a fair requirement or not is open to debate. But that font
>tags are forbidden couldn't be much clearer.

I disagree, as it is listed as an example/explanatory text, and not
as a strict rule to be followed.

>And we are not talking about
>the actual accessibility of the site in question, which, save the problems
>noted by Anne, is probably pretty accessible. We are talking about Triple-A
>compliance with the WCAG 1.0. And I'm sorry but it ain't, it don't, it
>won't, and it hasn't.

I said that I don't believe it's triple-A compliant.  However, I also
feel that your interpretations of specific checkpoints are incorrect.

>Frankly, Kynn, after reading many of your other posts on this subject, I
>believe that you have a *political* motivation for making the above
>statement.

I may very well have a *political* motivation, if by *political*
motivation you mean that I wish to see as many strides toward
accessibility as possible, and I realize that reasonable compromises
have to be made because the whole battle will be won by either (a)
voluntary compliance or (b) legislation and litigation.

>It seems clear to me (correct me if I'm wrong) that you believe
>that a strict interpretation of the WCAG guidelines will scare away a lot of
>potential converts. That's fine.

Yes, I believe that an overly dogmatic and unachievable WCAG document
will have no credibility, either with the designers (for voluntary
compliance) _or_ with the courts (where an "undue burden" argument
could be made), and this will lead to WCAG not being widely adopted.

I wrote in email to a WAI participant lately and said something to
the effect of, "I would rather see an 'easier' WCAG document which
overcomes most of the barriers and is easier to implement, and thus
gets adopted by nearly all web designers, than a 'stricter' WCAG
document which is thought of as unreasonable by nearly all web
designers and is thus ignored.'"

My analogy is this:  How many web designers consider (X)HTML Strict
to be appropriate for professional work, vs. (X)HTML Transitional?
(I'm not talking about those people who don't follow any standard;
I'm talking about informed, standards-supporting, well-meaning
professional web designers who believe in the importance of web
accessibility and universal design.)

Want a hint?  Both the W3C homepage and the WAI homepage are written
in Transitional.  (The WAI homepage isn't even written in XHTML but
in HTML.)

Fact:  _It has proven nearly impossible to convince web designers to use
Strict, but Transitional is an easier sell._  Even with that in mind,
the majority of web sites do not use standard HTML at all.

If only (X)HTML Strict were published, how many people would be using
it?  Here's a hint:  About as many are using it today.  Which means
that there would be an OVERALL DECREASE IN STANDARDS-COMPLIANT WEB
CODE, which means a number of serious problems including accessibility.

Now, I fear that a "strict" reading of WCAG will do the same thing.  Why
is that a problem?  Let me tell you.

** Because of the way that WCAG 1.0 compliance is structured (Single-A,
    Double-A, Triple-A, etc.), following checkpoints of a certain level
    is an all or nothing proposition. **

That may seem good at first.  It will "force" people to follow all the
priority 2 checkpoints, right?

Well, not right.  Instead what it does is it leads to situations in which
if a web designer considers _any aspect of Double-A compliance_ to be
unreasonable, then Double-A compliance itself becomes an unreasonable
task and it simply won't be done.

If I have the goal of supporting Netscape 3 browsers -- say that I
work at a University which has given me a mandate to support older
browsers -- and I want to use <font> to provide them with a nice
experience, a _strict_ reading of WCAG 1.0 states that the best I
can hope for is Single-A compliance.

"That's right," you may say.  "Compliance is a measure of accessibility,
and your site doesn't live up to the right standard.  Therefore it
can't claim Double-A compliance."

HOWEVER, the problem is that there are 20 other priority 2 checkpoints,
such as "use valid HTML", which you now will _not_ follow because it is
an all-or-nothing affair.

The problem really is with the compliance system, something which was
added on _after_ the priority system and at a very late date in the
WCAG 1.0 process; by the time I noticed it and complained very vocally,
it was far too late.  But make no mistake, the Single-A, Double-A,
Triple-A conformance system is -a barrier to increasing accessibility
on the web-.

It is an active disincentive to implementing checkpoints.

>But the solution is to change the WCAG as
>necessary to solve this problem, *NOT* to reinterpret it in whatever way you
>need to to accomplish your goal. Once you open that door, what's to keep
>anyone from doing anything they want and posting a Triple-A icon? Is this
>your goal? I doubt it.

No, of course not.  I would much rather have the Triple-A icon
eliminated, as I feel the entire conformance system is very poorly
done and has unintentional HARMFUL side effects.

>"Use style sheets to control layout and presentation" means exactly what it
>says: use style sheets. It does not say "Use HTML elements and attributes to
>control layout and presentation except when you feel like using style
>sheets."

It does not say -- save for an example, which I do not consider
as authoritative as a checkpoint -- that you should _not_ use those
elements.  It doesn't say "Use style sheets to control layout and
presentation and do NOT use markup to control layout and presentation."

If the two were _mutually exclusive_ it would say this.  However, that
is not the case now.

By the way, WAI home page claims Double-A compliance, and yet does not
use stylesheets for layout.  What are your feelings on this, Charles?

>Maybe I'm missing something here, but the English seems very plain to me and
>it is even my first language.

You are making the assumption that there is an unwritten "do not use
other things."  It doesn't say that.  It says you _should_ use certain
technologies, it is not a _negative_ checkpoint.

>Kynn continues to err in his ways:
>"Errors result when those are -relied upon- to provide information, not when
>they are -used-. That is a subtle but key point to understanding
>accessibility on the tag level."
>
>I reply:
>I'm not sure that this is true in all instances, but even if it is, what
>does this have to do with interpretation of the WCAG? There are certainly
>checkpoints in the guidelines that leave room for lots of interpretation
>(e.g., 14.1), but this isn't one of them. And while I'm all for adhering to
>the spirit of the guidelines rather than the letter, who gets to decide how
>far the interpretation goes? Are you suggesting that we should applaud
>people who ignore the guidelines that you don't like and claim Triple-A
>compliance anyway?

No, I'm claiming that people should produce accessible web sites and
should use WCAG -- sans the "broken" conformance system -- to measure
accessibility.  I don't think anyone should claim Triple-A compliance,
as I don't feel that's what the checkpoint priorities were for in the
first place.

Yes, I know we are "stuck with it" now, but I also feel that ALL of
WCAG is subject to interpretation -- clearly the WAI webmasters have
made their own decisions by using tables for layout (even though a
confusing untabler link is available) -- within reason.  I think that
a strict, dogmatic reading of WCAG is possible and has value, but I
refuse to believe that it is the only way to view these
_guidelines_ on how to create better web pages.

>Kynn gets really carried away:
>"Transitional XHTML is not deprecated. 11.2 does _not_ mandate the use of
>XHTML Strict."
>What does 11.2 say? It says:
>"11.2 Avoid deprecated features of W3C technologies. [Priority 2] For
>example, in HTML, don't use the deprecated FONT element; use style sheets
>instead (e.g., the 'font' property in CSS)."

So what does "avoid" mean to you?

>The difference between XHTML Strict and XHTML Transitional is that
>Transitional contains all the DEPRECATED ELEMENTS AND ATTRIBUTES and Strict
>does not. So if it validates as Transitional, but not as Strict, then the
>page must use deprecated elements or attributes and CANNOT meet guideline
>11.2.

So according to your interpretations, the WAI and W3C web sites are
not Double-A compliant, because they are Transitional.  Is that
correct?

>Note, 11.2 does *not* say, "Avoid deprecated features *when possible*." In
>fact, it doesn't leave any room for maneuvering at all. You want to be
>Double-A or Triple-A? Lose the deprecated elements.

No, you see, that's not going to happen.  Instead you're going to see
people _losing the Double-A compliance button_, not losing the
Transitional elements.  And that will be a loss overall, because it
means that _no_ Priority 2 or Priority 3 checkpoints will be followed,
_only_ the Priority 1 checkpoints, because the vast majority of web
designers do not find (X)HTML Strict to be appropriate for professional
work.

I don't really want to make anyone's legal arguments here, but I believe
that a standard which mandates practices which are -not appropriate
for professional work- stands a much better chance of being dismissed
as a poor standard.  And thus a strict intepretation of one or two
checkpoints (such as "you can only use HTML Strict") means a greater
chance that nobody will choose to use the Double-A conformance level.

With a reading as strict as you propose, _I_ sure would not want to
recommend that level of compliance to anyone.  As a professional web
designer since 1994, I believe it is clearly and obviously an
_unreasonable_ restriction -- and remember, I'm not some WYSIWYG-using,
Geocities-hosting, Javascript-stealing, standards-ignorant yahoo
who thinks he's a web "master."  I'm someone who lives and breathes
web accessibility every day, and _I_ find your level of strictness to
be far too high of a bar to be reasonable.

--Kynn

PS:  This is not an attack on the people who worked hard to produce
      WCAG 1.0.  This is a philosophical difference with one of the
      core mechanisms in WCAG 1.0, namely, the conformance system.
      My goal remains, as does everyone's here, to increase the
      accessibility of the web for all users, regardless of disability
      or disability type.

-- 
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/
Received on Thursday, 14 December 2000 21:33:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:50 GMT