- From: Eric Hansen <eghansen@yahoo.com>
- Date: Fri, 23 Apr 1999 16:18:17 -0700 (PDT)
- To: w3c-wai-gl@w3.org
This document contains some edits. Unless dated otherwise, they are from my 4/18/99 revision of the 4/16/99 version of the document. (That and other revisions are available from: http://etsr.digitalchainsaw.com/wcagpub/). Causes for the changes are various. One strategic issue: I think that there needs to be a balance between the several different kinds of alternative representations of information. I feel that we risk having strong adoption on #1 because we are placing too much emphasis on #2. #1. Text equivalents for non-text elements (movies, prerecorded audio, graphics, animations, applets, etc. [1.1]). #2. Text equivalents for text (linearizations of tables [10.3], summaries for tables [5.5], abbreviations of table headers [5.6], simplifications of text [14.1], expansions of acronyms and abbreviations [4.2]). #3. Non-text equivalents for text and for non-text elements ("graphic or auditory presentations" to "facilitate comprehension" [14.2]; "equivalents" for scripts, applets, etc. [6.3]; "equivalents" for dynamic content [6.2]). Within the last month or so we have made considerable progress in consolidating the many checkpoints into what is now checkpoint 1.1; refining the requirement for linearizations of tables, and in moderating the requirement for non-text equivalents (e.g., 14.2). I feel that some more refinements are still needed. I believe that modifications are still needed and well worth making because they are likely to increase adoption of the guidelines. == 14.1 -- Simplified Text Modify language to say: "Ensure readable language" or "Define difficult vocabulary" etc. and lower the priority to Priority 2 or Priority 3. See comments on: http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0066.html == 14.2 - Acronyms and Abbreviations {EH: Delete this. I think (4/23/99, added word "think") that this checkpoint is a "poison pill" that, while seemingly innocuous, places an untenable burden upon the Web developer. I think that it will discourage an inordinate number of people from striving for triple-AAA compliance and maybe the other compliance levels. If it must be retained, I suggest the following change: 4.2 Specify the expansion of first use of abbreviations and acronyms within a document. [Priority 3] For example, in HTML, use the "title" attribute of the ABBR and ACRONYM elements. Or, provide the expansion (especially of the first occurrence) in the main body of the document. Techniques for checkpoint 4.2} {EH: Old. 4.2 Specify the expansion of abbreviations and acronyms. [Priority 2 for the first occurrence of the acronym or abbreviation in a given document, Priority 3 thereafter.] For example, in HTML, use the "title" attribute of the ABBR and ACRONYM elements. Or, provide the expansion (especially of the first occurrence) in the main body of the document. Techniques for checkpoint 4.2} == 5.4 -- Summaries for Tables {EH: Delete this one. This should be put in the Techniques document and be entirely optional. It should not be required in order to obtain a triple-A rating, unless you want to qualify that this is for "highly complex tables." 5.5 Provide summaries for tables. [Priority 3] For example, in HTML, use the "summary" attribute of the TABLE element. Techniques for checkpoint 5.5} == 5.5 -- Abbreviations for Header Labels {EH: Delete this one. This should be put in the Techniques document and be entirely optional. It should not be required in order to obtain a triple-A rating. 5.6 Provide abbreviations for header labels. [Priority 3] For example, in HTML, use the "abbr" attribute on the TH element. Techniques for checkpoint 5.6} == 6.3 -- When Scripts, etc. Turned Off {EH: Important Bug. Delete Checkpoint 6.3. It seems that this merely covers ground already covered by checkpoint 1.1, which requires text equivalents for scripts, applets, and programmatic objects. Text equivalents from checkpoint 1.1, by definition, provide essentially the same function and must be available in any case. The reference to non-text equivalents in the example is gratuitous; if we want to say more about non-text equivalents, we should probably do it in checkpoint 14.2. Alternative pages are covered elsewhere. If the focus of checkpoint 6.3 is simply on ensuring that the system doesn't freeze up, then that is simply not a disability access issue and does not belong in the guidelines. {EH: Old. "6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1] For example, in HTML provide a text equivalent with the NOSCRIPT element or via a server-side script. Or provide a non-text equivalent (e.g., a snapshot in place of an animation, a video equivalent of an applet, etc.). For applets and programmatic objects, provide text equivalents. Refer also to guideline 1. Techniques for checkpoint 6.3 "} == 10.4 -- Place-Holding Characters {EH: Delete 10.4. This is one ought to be entirely optional. This is one that seems to be an unecessary incursion upon the visual look and feel of the system. As I recall from a conversation with an expert computer user who is blind, this is only a problem related to a very old browser. I seriously advocate removing this one. I would like us to not tamper with the preferred look and feel of the major of Web users unless it is absolutely essential. 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] For example, in HTML, do this for TEXTAREA and INPUT. Techniques for checkpoint 10.4} == 11.3 -- Receive According to Preferences {EH: Checkpoint 11.3 is impossible to plan for and should be deleted. It may be a "poison pill" because it could create a "responsibility" nightmare for people striving for or claiming triple-A compliance. It would repel people from claiming triple-A compliance. This is not essential to the success of the guidelines and it may be essential in order to avoid failure (at least at the triple-A level). 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) [Priority 3] Note. Use content negotiation where possible. Techniques for checkpoint 11.3} == 13.3 -- Site Layout 13.3 Provide information about the general layout of a site (e.g., a site map, table of contents, or navigation bar {EH: Added navigation bar. See deletion of checkpoint 13.5.). [Priority 2] {EH: Hopefully, this is almost impossible not to accomplish.} In describing site layout, highlight and explain available accessibility features.{EH: This sentence must be unenforceable and should be. Doesn't this suggestion run counter to the philosophy of universal design? Why single out people with disabilities if it is not necessary? I suggest putting it in the Techniques document as something to consider.} Techniques for checkpoint 13.3 == 13.2 -- Navigation Bars {EH: This should be deleted. Checkpoint 13.2 has a Priority 2 requirement for navigation. This is redundant. If necessary, the phrase "navigation bar" could be added to 13.3.} 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3] Techniques for checkpoint 13.5} == 13.6 -- Grouping Related Links {EH: This should be deleted. This could be a Technique for 13.4 or some other 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. [Priority 3] } Techniques for checkpoint 13.6 {EH: This should be deleted. It is far to wide open would not be necessary for small Web sites. This would make another fine technique or idea to consider. 13.7 Enable different types of searches for different skill levels and preferences. [Priority 3] Techniques for checkpoint 13.7} {EH: I am ambivalent about this. It is largely redundant with the techniques for checkpoint 14.2 and could be deleted.} 13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3] Note. This is commonly referred to as "front-loading" and is especially helpful for people accessing information with serial devices such as speech synthesizers. Techniques for checkpoint 13.8 == 13.9 -- Document Collections 13.9 Provide information about document collections (i.e., documents comprising multiple pages.), if available {EH: added "if available"}. [Priority 3] For example, in HTML specify document collections with the LINK element and the "rel" and "rev" attributes. Another way to create a collection is by building an archive (e.g., with zip, gzip, stuffit, etc.) of the multiple pages. Note. The performance improvement gained by offline processing can make browsing much less expensive for people with disabilities who may be browsing slowly. === Eric G. Hansen Development Scientist, Educational Testing Service ETS 12-R Rosedale Road Princeton, NJ 08541 (W) 609-734-5615, (Fax) 609-734-1090 Internet: ehansen@ets.org _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Received on Friday, 23 April 1999 19:18:05 UTC