RE: Politics: Strict Guidelines Considered Harmful

In my previous reply to Kynn I was half-joking. But this time I'm quite
serious and, frankly, a bit incensed. Here's why:

Kynn, I agree and agree and agree and agree with you. But then I disagree
about as strongly as it is possible to disagree.

I agree:
    That what is really important is the accessibility of the Web.

I agree:
    That the Web Content Accessibility Guidelines are an imperfect measure
of accessibility.

I agree:
    That the use of Single-A, Double-A, and Triple-A icons, especially as
they are currently instituted, may discourage some from following the
guidelines.

I agree:
    That many web developers are reluctant to follow the guidelines because
they appear too strict. (And many others just couldn't care less.)

I also agree that you have a right to speak up, to argue for a relaxation of
the guidelines, or a different policy regarding the qualifications necessary
to post an icon. But that's where my agreement with you ends.

Here is what you said:

"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."

That's nice. Bully for you. But who appointed you to reinterpret the WCAG to
make it "easier"?

The Web Content Accessibility Guidelines are the result of a community
effort. The working group, this list, and a variety of others throughout the
community at large cooperated to create these guidelines. It may be true
that the guidelines are too strict to be politically viable. It may be true
that the all-or-nothing icons are a disincentive to many professionals. It
may be true that another approach would be better. But it is not your place
to make these decisions for all of us.

That is why there is a working group. That's why there are discussion lists.
If the WCAG is to be reinterpreted, it is the community as a whole who must
agree to that reinterpretation. You have no right to unilaterally
reinterpret it in a way convenient to you and to your political views and to
present that interpretation here (and, presumably, elsewhere) as if it were
the one, true interpretation.

There are certainly many checkpoints on the list that are open to
interpretation and discussion. 14.1 "Use the clearest and simplest language
appropriate for a site's content" is a good example. But this is an
interpretation that must be decided on a case by case basis.

Most of the guidelines do not offer that much room. Take 11.2, "Avoid
deprecated features of W3C technologies." You ask, "So what does "avoid"
mean to you?" Well, let's look at the guidelines:

7.2 Until user agents allow users to control blinking, avoid causing content
to blink....

Now you tell me, what does "avoid" mean? Does it mean that it's OK to blink
sometimes? We can accept a certain number of epileptic seizures? Or does
avoid mean DON'T DO IT? And if it means DON'T DO IT here, why would it mean
something else when applied to deprecated features?

If you really want to argue that this is unclear, or means something other
than what it says, then I won't bother responding further. You will have
destroyed your own credibility, as far as I'm concerned. Does anyone else on
this list think that "avoid deprecated features" means "only when you feel
like it"?

Now we can re-interpret 11.2 to mean "when it directly affects
accessibility" and we can argue about when that might be, but the operative
word here is WE. Not Kynn, all on his own, riding in to save us from
ourselves. We, the community as a whole, must agree to that. Better still,
an official word from the W3C would be nice. Or better still, how about a
Version 1.1? Why wait for Version 2? If the document really is a barrier
rather than an aid to accessibility, and rewording a few checkpoints to
loosen them up a bit will fix it, why not do it? That way it would be
supportive of and supported by the community, rather than the result of an
end run by one person.

Let's look at a couple of other checkpoints, just for good measure. What is
the potential consequence of unilateral decisions regarding what the
guidelines say? How about this:

My page is full of elements like this: <b><i><font face="Nuptial"
color="#999999" size="1">some important text!</font></i></b>. And let's say
I have a table to lay it all out and the table is full of single-pixel gifs.
Then at the top of the page I put this:

<style type="text/css"> body {background: #ffffff} <style>

Have I met the requirements of checkpoint 3.3: Use style sheets to control
layout and presentation? Really? Does anyone else on this list think so?

Where does it end?

3.4 Use relative rather than absolute units in markup language attribute
values and style sheet property values.

OK, I'll add font-size: 1em; to my style sheet above. Great! Now I've met
checkpoint 3.4! Never mind the font tags with size="1" in them.

Oh, and I used an <h1> element for my page title, so now it's OK if all my
subheads use <font size="7"> because I'll still meet checkpoint 3.5: Use
header elements to convey document structure and use them according to
specification. After all, I used *a* header element and I used it according
to specification.

Please tell me, Kynn, which other checkpoints don't mean what they say?
Funny how the authors thought to add qualifications to some, such as "Until
user agents provide...," but failed to qualify "Use style sheets to control
layout and presentation" with the words "except when it's convenient to use
presentational tags, tables, single pixel gifs, etc." Or could it be that
they didn't intend to qualify it?

The WCAG is written in plain English. It is not difficult to understand what
most of these checkpoints mean, though it may be difficult to accept. Taking
the document at face value is not a "strict" interpretation, in fact, it is
hardly an interpretation at all. That is why it is called "face value." If
the WCAG needs to be changed to make it looser, then by all means let's
change it. But let's at the very least agree to this as a community and
preferably get the W3C's approval, too. Better still, let's change the
wording of the guidelines so that, taken at face value, it will mean what we
want it to mean. While we're at it, we can revamp the Single, Double,
Triple-A system to something better, too.

Am I getting through to you, Kynn?

Charles F. Munat,
Seattle, Washington




-----Original Message-----
From: Kynn Bartlett [mailto:kynn@idyllmtn.com]
Sent: Thursday, December 14, 2000 6:16 PM
To: Charles F. Munat; w3c-wai-ig@w3.org
Subject: Politics: Strict Guidelines Considered Harmful


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 Friday, 15 December 2000 02:51:01 UTC