- From: Andi Snow-Weaver/Austin/IBM <andisnow@us.ibm.com>
- Date: Thu, 14 Sep 2000 15:55:46 -0500
- To: w3c-wai-gl@w3.org
Reposting - forgot the subject last time..... Andi andisnow@us.ibm.com IBM Accessibility Center - Special Needs Systems (512) 838-9903, http://www.ibm.com/able Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo ---------------------- Forwarded by Andi Snow-Weaver/Austin/IBM on 09/14/2000 03:54 PM --------------------------- Andi Snow-Weaver 09/14/2000 02:55 PM To: w3c-wai-gl@w3.org cc: From: Andi Snow-Weaver/Austin/IBM@IBMUS Subject: I think Jason's rewrite is a step in the right direction. Some specific comments below.... At 11:50 AM 9/9/00 +1100, Jason White wrote: > Draft Reformulation of Web Content Accessibility Guidelines > >Principles and Guidelines > > Principle 1: Design content which can be presented visually, auditorily >or tactually, according to the needs and preferences of the user. >WL: I believe that we might infer some "and/or"ness by using >"visually/audibly/haptically". AS: I like Jason's rewording of Principle 1. The previous wording "All information must be available entirely...." made it sound like the web author has to provide all the different renderings. The rewording above conveys more of an enabling spirit which is what I think we want. > Guidelines > > 1.1 Ensure, by providing textual equivalents to auditory and graphical > presentations as necessary, that every component of a document, > web page or multimedia presentation can be rendered as text in > a standard character set. > Note: a textual equivalent can take a variety of forms. It is > intended to fulfill the same function, and serve the same > purpose as the auditory or visual presentation to which it > provides an alternative. Thus, in writing a textual equivalent, > it may be appropriate, in some contexts, to provide a short > label or descriptive phrase that can be substituted for the > auditory or graphical material. In other circumstances, > however, a longer explanation, description or exposition may be > required. A textual equivalentmay consist of structured content > or metadata, if appropriate. >WL: Why do I prefer "text" to "textual"? Also to me everything between >"Ensure" and "that every" can be eliminated. And I would like to see the >"text equivalent" note elsewhere as a linked-to glossary item. AS: I feel just the opposite of William. I think the guideline is "Provide text equivalents to auditory and graphical presentations." The rest of the guideline is the rationale for why you need to do this. BTW, I also prefer "text" to "textual". > 1.2 For any time-based multimedia presentation (e.g., a movie or > animation), synchronize the textual equivalents (e.g., captions > of the audio track or descriptions of the video track) with the > presentation. > This guideline applies to multimedia presentations which have > auditory and visual components. Where one component (either the > audio or video track) contains no significant information, a > synchronized caption or description need not be provided, > though a textual equivalent, for example a description which > can be retrieved by the user in place of the multimedia > presentation, is still required (see guideline 1.1). >WL: I hope that there is really some need for this elaborate an >explanation. Whoever spoke of "hidden text" was probably thinking of having >a way of leaving the "This guideline applies" paragraph in a place where >those who got the idea from the first stating of the guideline from being >faced with explanatory material that, for them, was unnecessary. AS: Jason asked in another posting if this rewording incorporates my suggestions for this guideline. I think Jason's rewording covers the ideas in my suggestion but it is more obtuse. > Principle 2: Separate content and structure from presentation, and ensure > that significant structural or semantic distinctions are captured > explicitly > in markup, or in a data model. > AS: "...and ensure that...are captured..." is passive. Suggest rewording as "....and capture significant structural or semantic distinctions explicitly in markup or in a data model." I also wonder about the choice of the word "capture". To me, capture implies that something exists somewhere else and you have somehow acquired it for your own use. Would "provide" or "define" convey the right meaning? > Guidelines > > 2.1 Use markup languages properly and in accordance with > specification. > This guideline requires not only that document instances comply > with any formal grammar or other test of validity provided for > in the relevant markup language specification, but also that > structural elements, attributes etc., be used to convey the > meanings which have been assigned to them in the secification. > WL: This is a perfect place for external elucidation. Many people are >clueless as to "proper" use of ML. And "grammar" has a specific meaning >that conflicts with *most* readers' experience of that term. The "how" of >conveying assigned meanings is also a candidate for elaboration. Many >(most?) authors are unaware that italics are other than a prettification or >that H1 is structure - whatever that is. AS: The first sentence of this guideline is not understandable without the explanation below. Further, the explanation expands to two requirements. I still think this would be simpler, but still accurate, if split into two guidelines: 2.1(a) Use standard markup languages and data models. Do not use non-standard extensions. For example, use XHTML that validates to the XHTML specification. 2.1 (b) Use markup elements to identify the type of content being presented, not to control presentation. For example, use the HTML <blockquote> tag to identify quotations, not to achieve paragraph indentation. > 2.3 Use style languages, where available, to control layout and > presentation. Where practicable, provide (or link to) multiple > style sheets, each supporting a different output device. > Style languages permit a high degree of separation to be > maintained between content and presentation, by allowing the > rules which control the rendering of the content to be > separated from the markup codes that denote its structural > features. Typically, style rules are stored separately from the > content to which they apply, in resources which are referred to > in these guidelines as style sheets. To facilitate the > presentation of web content by a range of devices (high and > low-resolution displays, printers, speech devices, etc.), it is > advisable to associate a variety of style sheets with your > documents. >WL: Perhaps I'm overly concerned with "tersification" but it seems that if >this is to be read as an entity that the explanations should be "hideable". >In the legal analogy a constitution doesn't explain in this much detail >what "freedom of speech" maps to. AS: I don't know if we have to "hide" it as William suggests but with the proper HTML markup, the first sentence can be communicated as the terse guideline and the rest as backup explanation. For example, use <h3> or <h4> for the first sentence. The rest is a followup paragraph. This comment applies to all of the guidelines. > 2.3 Where presentation is used to communicate distinctions of meaning > or structure within the content, ensure, if possible, that > these distinctions are captured in equivalent data or markup > which can be obtained and accessed by a user agent. > It should be noted that, in accordance with the above > requirement, the structural markup or metadata, and the > presentation, respectively, need not reside in the same file or > logical resource. Thus, purely presentational versions of the > content (e.g., in a graphical format or a page description > language) may be provided, so long as there exists a version > which can be retrieved by user agents and contains markup which > preserves the same structural and semantic distinctions that > are implicit in the "presentational" version. In such > circumstances, techniques of content negotiation may be used to > select the version which best meets the user's requirements. >WL: Note that "the structural markup or metadata, and the presentation, >respectively, need not reside in the same file..." is pretty much what all >my above comments signify only instead of >"markup...metadata...presentation" it's about >"explanation...definition...elaboration". AS: My earlier comment about passive voice applies here too; i.e. "...ensure ... is captured..." > 2.4 Do not rely on presentation alone (E.G. colour or font changes) to > express semantic distinctions. > This is a corollary of the preceding guideline. It should not > be interpreted as discouraging the use of colour or other style > properties to enhance the presentation of content. It can be > satisfied by ensuring that the distinctions conveyed by the > presentation are also reflected in the markup. AS: A more positive wording of this would eliminate the need for the disclaimer about discouraging the use of color or other style properties. Suggest: "2.4 Use presentation (e.g. color or font changes) to enhance semantic distinctions but not as the only means to understand them. > > 2.5 Ensure that the logical structure of the content is preserved in > the markup or data model, together with any additional semantic > distinctions that facilitate rendering of the content in the > visual, auditory and tactile modalities. > The logical structure of the content needs to be explicitly > preserved for two purposes. First, it allows style rules (other > than those provided by the author) to be applied, thus enabling > the content to be presented effectively and appropriately in > different modalities, with a range of output devices. Secondly, > it provides the basis for structural navigation by the user. In > order for the content to be rendered in all three modalities, > it is also necessary to capture such distinctions as emphasis > and changes in the natural language or notation in which the > text is written. Note also that if this guideline is followed, > it will enable more sophisticated analysis of the content by > search engines and other document processing applications. >WL: Ditto this one. The problem with putting *some* of the required >explanation in the guideline itself is that it's very difficult to decide >which terms need elaboration, e.g. for me "data model" has no "what" to it. >I couldn't tell you what that means. AS: Another passively worded guideline: "Ensure ...is preserved..." Also, I have the same problem with the word "preserved" as I do captured. "Preserved" implies that it exists already and you are maintaining it. Suggest " Use markup or a data model to provide logical structure to the content, together with any additional semantic distinctions that facilitate rendering of the content visually, auditorily, or tactually." BTW, I'm not sure what "additional semantic distinctions" means. > Principle 3: Design for ease of comprehension, browsing and navigation > > Note: this principle is applicable only in circumstances in which the > web content consists of a document or user interface which is intended > to be presented to a human reader. A structured data base or > collection of metadata, in circumstances where the user interface is > supplied entirely by the client application, lies outside the scope of > this principle. >WL: I'm not sure that this principle doesn't apply equally to "machine >readability", in other words you must also follow the rules for "machine >comprehension, etc." if there is such a thing - and I think there is. > Guidelines > > 3.1 Use a consistent style of presentation in which the structural and > semantic distinctions expressed in the markup, are associated > with appropriate formatting conventions that enhance the > readability and intelligibility of the content. > The purpose of presentation is to communicate the meaning of > the content, as effectively as possible. Thus, to aid > understanding, it is vital that the structure and semantics of > the content be readily apparent from the presentational > conventions chosen by the author. >WL: As to whether the purpose is to communicate the meaning: this is where >there is some divergence with a huge body of practitioners who think the >purpose resides as much (or more) in "fashion" as in what we usually think >of as "content" - if it's "cool" not much else matters. > 3.2 Provide clear and consistent navigation mechanisms throughout a > document or web site. > Such navigational mechanisms may include logically organized > groups of hypertext links, an overview or table of contents, a > site map (with an appropriate textual equivalent; see guideline > 1.1), an index, etc. They should be easy to locate within the > over-all structure of the content and consistent across web > pages or related documents. > > 3.3 Divide large blocks of information into more manageable groups > where natural and appropriate. > For example, divide user interface controls into logically > organized groups. Use headings, paragraphs, lists etc., > appropriately to communicate relationships among items, topics > or ideas. > > 3.4 If search functions are provided by a web site, enable different > types of searches for different skill levels and preferences. > Examples needed here. > > 3.5 Place distinguishing information at the beginning of headings, > paragraphs, lists, etc. > Examples? Explanations? > > 3.6 Use the clearest and simplest language appropriate for a site's > content. > This guideline is intended to facilitate comprehension of the > content by all readers, especially those with cognitive > disabilities. It should not be interpreted as discouraging the > expression of complex or technical ideas. Authors should > however strive for clarity and simplicity in their writing, and > review the text with these considerations in mind prior to > publication on the web. > > 3.7 Supplement text with graphic or auditory presentations where they > will facilitate comprehension of the content. > Auditory and graphical presentations can do much to improve the > comprehensibility of a web site, especially to people with > cognitive disabilities or to those who are unfamiliar with the > language in which the textual content is written. Note that > material provided in auditory or visual forms must also be > available as text (see guideline 1.1). >WL: The clear implication of 3.7 is that *this* document's comprehension >cannot be improved with these devices. If we *say* it and don't *do* it, >then... I submit that the "language in which the textual content is >written" in this case makes a great many people think that English must be >our "second language" after whatever we call what we use in these >documents. I mean if we are saying that graphic/auditory can improve >comprehensibility and then don't use them, something's amiss. > 3.8 Use headings, labels and titles appropriately to identify > structurally significant divisions within the content. > For example, use headings to identify important topics or > subdivisions within a document. Label table headers, user > interface controls and other complex structures within the > content. Note that in addition to full, descriptive labels, it > may also be appropriate, in designing complex structures such > as tables and forms, to provide abbreviated labels which can be > used when the content is rendered on small displays or via > speech output. >WL: This part we actually do in the documents, but the previously >alluded-to stuff is totally ignored *except in passing reference*. > 3.9 Provide an overview or summary of highly structured materials, > such as tables and groups of user interface controls. > A discussion of which types of structures should be considered > complex, and the circumstances in which this guideline applies, > should be added here. > > 3.10 Define key terms, and provide expansions for abbreviations and > acronyms, which should be identified using appropriate markup. > Note: only the first occurrence of an abbreviation or acronym > occurring in a document need be expanded. Expansion > dictionaries, for instance in metadata, may be provided as an > alternative to an expansion in the text of a document. >WL: I may feel different in the morning but right now this seems at a >different level than what's gone before. > Principle 4: Design user interfaces for device independence > > Note: this principle applies only where the content provides its own > user interface (for example as a form or programmatic object). >WL: I'm again not sure that this is an "only". Device independence is so >loaded for me right now that I think that for the first time in the >document I'm actually looking for expansion! > Guidelines > > 4.1 Associate an explicit label with each user interface control. > This guideline applies not only to individual user interface > controls, but also to groups of such controls, which should > likewise be provided with descriptive labels. > > 4.2 Ensure that user interface controls are grouped logically. > Note that there is an upper limit to the number of user > interface controls that should occur in a single group; see > guideline 3.3. > > 4.3 Ensure that event handlers are device-independent. > Examples? > > 4.4Design user interfaces to be compatible with assistive > technologies. > Use standard software conventions to control the behaviour and > activation of user interface components. Note that > platform-specific guidance may be available for your operating > system or application environment. >WL: There's some message about the beleaguered area of "Universal Design" >available for this section but I may just be dreaming in that regard. > Principle 5: Design content to be compatible with the features and > capabilities of user agents, including those which only support older > technologies or standards. > > Guidelines > > 5.1 Make sure that web sites which take advantage of newer > technologies continue to be usable when such technologies are > turned off or not supported. > Note: it may be desirable to provide multiple versions of the > same content in order to ensure backward compatibility. In > determining the extent to which older technologies should be > supported, content designers should bear in mind that assistive > hardware and software are often slow to adapt to technical > advances occurring in other areas, such as web-related > standards. Also, for significant groups of users, it may not be > possible to obtain the latest software or the hardware required > to operate it. >WL: What? No "graceful transformation" - thank you! > 5.2 Avoid causing content to blink or flicker otherwise than under the > control of the user. > Note that although some user agents may permit blinking or > flickering to be suppressed, this is not universally the case. > Content designers should therefore exercise special care in > avoiding such presentational effects. >WL: Someone recently mentioned that whenever one pushes the "next page" >control there is technically a "blink". In all I think this gets more >attention than it deserves, but so be it. I remember the old "blink" >feature in DOS with amused disgust. It was a drag then and it's still a >drag but... I've never (personal prejudice?) thought this rose to the >"guideline level". > 5.2 Avoid causing pages to be refreshed or updated > automatically, otherwise than in response to a user's request. > Note that this requirement can be satisfied by providing an > option to deactivate automatic updating, or to control the rate > at which it occurs. User agents may also offer control over > this effect. >WL: Good enough. > 5.3 Where it is likely that some user agents will not support the data > format or encoding in which the content is supplied, provide > metadata, a transformation filter, a style sheet or other > mechanism to enable the content to be processed by the user > agent. > This requirement is especially relevant in circumstances where > a data format or markup language which is not widely supported, > by default, in user agent software is relied upon. Note also > the discussion of backward compatibility in guideline 5.1. >WL: Again the much appreciated absence of "graceful transformation". >I think this has been a remarkable and on the whole excellent realization >of the "work item" posed some months ago to provide a more abstract/general >statement of the principles of accessible Web design. My above quibbles are >really rather minor and I think it's close to what I hoped for. As to what >it does for anybody else... >-- >Love. > ACCESSIBILITY IS RIGHT - NOT PRIVILEGE Andi andisnow@us.ibm.com IBM Accessibility Center - Special Needs Systems (512) 838-9903, http://www.ibm.com/able Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo
Received on Thursday, 14 September 2000 16:57:29 UTC