- From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
- Date: Fri, 18 Feb 2000 19:04:43 -0800
- To: "Gregory J. Rosmaita" <unagi69@concentric.net>
- Cc: thatch@us.ibm.com, WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
At 12:55 PM 2/18/2000 , Gregory J. Rosmaita wrote: >as someone who has designed, constructed, and maintained web sites for educational, non-profit, and for-profit entities, i couldn't disagree more... what is the extra expense entailed in adding ABBR or ACRONYM to page content? this is the same argument that has traditionally kept ALT from being routinely deployed, despite the fact that it is a required attribute of IMG in HTML 4.0/4.01 Hi, Gregory, you know I love you and so I know you won't take this the wrong way, but I'm going to have to disagree with a few points and state that I think Jim Thatcher's points need to be considered seriously. There -is- extra expense that would be involved in -- to use Ann Navarro's example -- making sure that the HWG site uses ABBR consistently. The costs, as I see them, would include: * The cost of deciding how and when to use ABBR, which is not trivial. There's still not a consensus that I'm aware of that specifies when you need to use ABBR around a particular bit of text. * The cost of training my volunteers in how to use ABBR correctly; this is a time cost to both me and those web site volunteers. * The cost of reviewing our pages and finding places where ABBR should be used in accordance with our new policy; this means a full review of the entire site INCLUDING viewing source repeatedly, so it's not a trivial task and someone (me?) would have to do this. * The cost of actually making the changes to existing or new pages; this could be trivial or it could not be. In the case of the HWG, we'd have to do a lot of work because we have a lot of pages that use abbreviations and acronyms extensively. >your caution about being selective in what we ask for from content developers because of cost simply doesn't wash... what we are actually doing is two-fold -- 1) asking content developers to design and implement with accessibility in mind, and 2) to compensate for the shortcomings of the existing technology upon which they are umbilically reliant, in particular, the well-documented shortcomings of authoring tools... I agree that's what we're asking, but what you ask is too vague, because it leaves -unanswered- some questions. You say that they should "design and implement with accessibility in mind" -- but to what extent? To what degree is it necessary to be "accessible" and what does that mean? In my opinion it should be based on whatever the content developers feel is acceptable, but that requires content developers to be both sensitive to the needs of people with disabilities (which is an education problem) and also to be, themselves, experts on accessible web techniques so that they can decide what to implement (also an education problem)! In short, you're asking them to be Gregory, or Kynn, or Jim Thatcher, or Phill Jenkins, or Dick Brown -- all people who can rightly be considered web accessibility experts, and note that we don't all agree ourselves! (As an aside, I identified the problems as education problems -- is it any wonder that I consider myself a web accessibility educator? This is probably the right field to be in, there's quite a need for it! *grin*) >that is where the true expense lies -- in evaluation and repair, not in education and implementation... But we -can't- dismiss that expense. Note that even trained designers who are experts in accessible design -- such as my wife, who ensures that every page she creates can be used in all the AWARE Center lab's browsers and can pass Bobby and WCAG single-A -- _must_ spend time using evaluation and repair tools as part of the process. She could skip checking it with Lynx, or pwWebSpeak, or JAWS+MSIE, sure -- and that WOULD save costs. The fact that she cares about web accessibility -does- mean extra cost to our clients. (But as I explained before, nobody has complained and they all manage to see the value inherent in that cost. But there -is- a cost.) >what do most web content providers learn when they take courses on web design/construction? even at the most prestigious of educational institutions, they very rarely learn the grammar and syntax, they almost never learn the why behind the how, but are merely given an expensive introduction to a particular authoring tool's interface... Hey, don't overgeneralize, the HTML Writers Guild's online classes in web design include information on accessibility. :) I guess that just goes to prove that we're ABOVE the category of "most prestigious of educational institutions." :) :) :) >my argument isn't the only argument for implementing the accessibility features that PF has worked so diligently to get integrated into W3C promulgated markup languages, but it is one aspect of the broader solution -- endowing the greatest possible number of individuals with equivalent read AND write access to the web... Gregory, you know I agree with you in principle, and in principle something like ABBR should be widely implemented. However, companies -will- need to prioritize sometimes, and thus we can't afford to have an "all or nothing" view of the web. Sometimes they WILL need to draw the line, and if we (the WAI, the AWARE Center, or just Gregory and Kynn, general web goofballs) can clearly explain where, when, why, and how to draw that line, I think it's useful. Phill and Jim believe that the line can be drawn on this side of the ABBR tag, because it's not widely supported. You disagree -- but I think the criteria they use to draw that line is appropriate. You (or even I) might draw the line differently, but we *have* to at least look at it and not simply say "the principle is that we will encourage everything that's Good and Proper even if it's currently worthless." That's a very quick way to turn off a lot of people who otherwise would be willing to listen to us. -- Kynn Bartlett mailto:kynn@hwg.org President, HTML Writers Guild http://www.hwg.org/ AWARE Center Director http://aware.hwg.org/
Received on Friday, 18 February 2000 22:10:47 UTC