- From: Kynn Bartlett <kynn@idyllmtn.com>
- Date: Thu, 14 Dec 2000 18:16:21 -0800
- 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 UTC