- From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
- Date: Wed, 20 Dec 2000 09:59:05 -0800
- To: "Bailey, Bruce" <Bruce_Bailey@ed.gov>
- Cc: "'Frank Tobin'" <ftobin@uiuc.edu>, "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>
At 06:29 AM 12/20/2000 , Bailey, Bruce wrote: >I am confused by this position. It seems to me that going from double-A to >tripple-A is not that much work. What are the checkpoints that are onerous? Fair question, let's take a look at the Priority 3 checkpoints: In General (Priority 3) 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. This can be difficult especially if it is demanded that the word be expanded _regardless of audience_ and if it is demanded that it be encoded using _markup_ and not naturally as English allows for. In other words, with a strict interpretation, this quickly becomes onerous -- and we've seen in recent days that many people are very quick to demand strict interpretations. 4.3 Identify the primary natural language of a document. This is easy and is done via template. 9.4 Create a logical tab order through links, form controls, and objects. This is harder, as there are few tools which support and create TABORDER attributes, and it's difficult to test. 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. This is a nightmare to enforce, for two reasons: (1) Technology-wise, keyboard shortcuts via ACCESSKEY are very difficult to include and make usable in any reliable method. Different meta keypresses on different operating systems and no reliable way to indicate hot keys compound the primary problem of there being few "safe", unused ACCESSKEYs to use. (2) The word "important" means this is another interpretation issue, which means that if you're a designer you will choose your own comfort level, and then someone who wants to prove your site "non-compliant" will adopt a stricter standard and "prove" that you fail Triple-A. 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. Anything which is labeled "until user agents" is automatically going to be a problem, especially as the average web author, with no experience with assistive technologies, has no idea whether or not this guideline should be followed. Heck, I don't even know this one -- can someone tell me whether or not user agents currently render adjacent links distinctly? How can someone know whether or not they are Triple-A compliant based on this? If I choose wrong, then someone will produce an obscure, older user agent, and will be quick to point out that I am in violation of this rule. 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) This is so broad and overreaching as to be impossible to meet. What does it mean? The following "note" states that content negotiation should be used "whenever possible." Vague, vague language which you can drive a truck through, or alternately block off the highway entirely! This checkpoint seems to be saying that you should provide a version of all content in any language requested by the user, and in any data format! Do you disagree? If you do, then what _is_ this checkpoint saying, and how do you know if it's checked? From a strict standpoint, this is very much demanding alternate formats and alternate language versions, but _without limit_, which pushes it far into the "onerous" realm of things. From a non-strict standpoint this checkpoint says _nothing_. (I will note, however, that this checkpoint itself is an excellent argument for everyone to use Reef's Edapta technologies, coming to a website near you in 2001!) 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. This is potentially onerous because it demands a specific presentation form and type -- "navigation bars" -- which is both an intrusion on the ability of the designer to create as she wishes, -and- an assumption that "bars" are always going to be the best way to provide access to navigation features. It's onerous because it's mandating one specific solution and pretending as if it's the best way of doing things. Also, "navigation bars" are never defined, and are certainly not a construct which is present within HTML itself -- so how do you know if you've met this checkpoint? 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. Have user agents provided that yet? Anyone, anyone? (Again, this illustrates the difficulty in anything labeled with "until user agents" -- which is why it will likely be eliminated completely in WCAG 2.0.) This is onerous because, when using a single-source/single interface model, there's no way beyond the hack of "invisible gifs" to include a "skip navigation" function for screenreaders without making the appearance unattractive, confusing, and unusable for graphical/visual users. 13.7 If search functions are provided, enable different types of searches for different skill levels and preferences. This is difficult and I'm not even sure what it means. Does it simply mean an "advanced" search in addition to a straight-forward box-and-button? Or does it mean something else? The techniques document suggests the following: "Search engines might include a spell checker, offer "best guess" alternatives, query-by-example searches, similarity searches, etc." Incorporating those types of search functions is not nearly as simple as adding a tag to an HTML document; writing (or even installing) a search engine is difficult work. By a strict interpretation, all of the above could be considered required -- as the checkpoint is another one which is very vague. If I don't include a spellchecker in my search engine -- if you can't find "constable" by typing "constible" -- then someone with a view to disprove my Triple-A status could easily conclude that I have not adequately met this checkpoint, and I will need to rewrite my search engine in order to gain Triple-A compliance. Onerous. 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. This is a "comprehension" checkpoint and it basically says that if you don't use journalistic "inverted pyramid" style writing, then you are in violation of this checkpoint and not compliant with Triple-A WCAG 1.0. This is clearly onerous as it assumes one model of writing. And from a strict perspective -- if I find one paragraph where the main concept is in the second sentence and not the first, am I in violation? How do you judge writing guidelines objectively? Do you apply this to forms of communication _besides_ simply news reports? Granted, this model makes sense for news sites, but what about other forms of written expression? By this checkpoint, you're unable to use any other model for writing text -- "front-loading" is mandating, and if you violate it at all, you are not Triple-A compliant. Onerous. 13.9 Provide information about document collections (i.e., documents comprising multiple pages.). This seems rather simple at first glance, but then it quickly becomes onerous because there is no limit or guidelines on how this should be done. Should the whole site be available as a tar or zip file? If not, then how do you know if you are in violation? What if the site is updated regularly, as a new site? Do you need to generate zip files of the site whenever it is updated? How big of zip files do you create to allow offline reading? What if your site is dependent upon server-side effects to function? Do you need to engineer a version of the site which is not thusly dependent? Do you create javascript equivalents for your server-side scripting, and if so, what do you do if those are not accessible? Heading into the area of link tags and rel/rev elements, what do you do about the fact that the tools provided in HTML are generally insufficient for describing the relationships between your document collection? The attribute values given are not enough to completely describe inter-site content relationships. What then? Does this checkpoint mandate a complete RDF map of your site? Who can tell? It's vague enough, with no limits, that you never know when you have met this checkpoint, and someone with a strict interpretation can always decide that you haven't met it because you don't have complete RDF graphs. Onerous. 13.10 Provide a means to skip over multi-line ASCII art. This faces the same problems as skipping over anything -- there is no way, beyond resorting to a very inappropriate hack, to allow ASCII art to be skipped by screenreaders while still providing a decent, usable, non-confusing interface to visual users. (Well, no way if you are using a single interface model. In Reef's Edapta structure, this problem becomes trivial.) Slightly onerous, mainly just tacky. 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. Aha! Here is the "Anne Pemberton" checkpoint! I was waiting for this to come up. Note to Anne: While I agree with you that this is important, I also feel that the checkpoint above is very, very vague and not properly worded to allow for conformance claims. Here's the problem. First off, "where they will facilitiate the comprehension" is clearly vague beyond belief. As with many other checkpoints, there is no way to know, beyond just making your own best guess, whether or not you have complied. And whenever a web designer is relying on her own judgment, that opens her up to the claim that she "hasn't done enough" because someone can easily adopt a stricter viewpoint and thus disqualify the site from Triple-A compliance. In other words, she may feel that she included "enough" graphics, but I may say "no, if you had done <this> over <here>, then you would have made comprehension easier, and thus it is demanded by this checkpoint that you do this." Secondly, while cheap clip-art is freely available and easy to come by, professional-quality illustrations and sound enhancements are not cheap or easy at all. Adding well-done graphics to a professionally done, commercial site is a major undertaking and may requiring hiring additional staff in most cases. Thirdly, without any standards on how to present graphical information, this checkpoint becomes very hard for a web designer to meet. There are no universal icons which represent the scope of all data, and any choices made will be subject to second-guessing after the fact. Conclusion: Onerous, as written. (Although I do believe strongly in the concept, just not in this specific way of expressing that concept.) 14.3 Create a style of presentation that is consistent across pages. Someone define "consistent"? How consistent must you be? What does it relate to? If you change colors for different sections, is that consistent or not consistent? Across how many pages must you be consistent? What if different groups of pages are controlled by different people? I worked at Claremont Graduate University as the web communications manager for almost a year. Each department within the school was allowed to create their own style for their web pages -- and we didn't do any checking to make sure that they were consistent within those styles, by the way. We just asked that they link back to CGU's main site using the CGU graphic, and we supplied a "default look" for the main site which they were welcome to use. Did this go far enough? Is this Triple-A compliant? Or is it not? The W3C's site itself is notorious for having 57314786173803 different styles; each technical release seems to have its own stylesheet! (Compare, for example, the HTML 3.2 and the HTML 4.0 documents.) The WAI homepage and the W3C homepage are different. Is this an accessibility violation? Or because they all have a link to the W3C home page, with the W3C logo on it, is that enough? In short: Good intent, poor checkpoint, and thus onerous. And if you use images and image maps (Priority 3) 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. This isn't too hard. Except, of course, for the "until user agents" which means that it's effectively impossible for most people to know when they are in compliance and not. Slightly onerous. And if you use tables (Priority 3) 5.5 Provide summaries for tables. Could be difficult when dealing dynamically generated content, but in general this is not very hard at all. 5.6 Provide abbreviations for header labels. Not onerous. 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. Onerous. Uses the "until user agents" clause which requires full knowledge of all assistive technologies, plus it requires you to duplicate content or else provide some sort of coding (which is not standard on web servers) to unstack tables. And this may not even be necessary! And if you use forms (Priority 3) 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. Somewhat onerous just from the "until user agents" phrase. Hope this analysis helps! --Kynn -- Kynn Bartlett <kynn@idyllmtn.com> http://kynn.com/ Director of Accessibility, Edapta http://www.edapta.com/ Chief Technologist, Idyll Mountain Internet http://www.idyllmtn.com/ AWARE Center Director http://www.awarecenter.org/ What's on my bookshelf? http://kynn.com/books/
Received on Wednesday, 20 December 2000 13:39:03 UTC