- From: Charles McCathieNevile <charles@w3.org>
- Date: Fri, 12 Mar 1999 18:18:14 -0500 (EST)
- To: WAI GL <w3c-wai-gl@w3.org>
- cc: pschmitz@microsoft.com
Patrick Schmitz' comments on the Guidelines document, annotated first by Ian Jacobs, with my further comments interspersed - look for PS: IJ: and CMN: (some of Patrick's points, along with Ian's response, have been snipped) Patrick Schmitz wrote: > > It is great to have a document like this, and I think that it has great > potential to improve web content with respect to accessibility. As a guide > to toolmakers, it should help as well. I do think that it strikes a tone > that design is not as important as accessibility, which may not go over too > well with some authors. IJ: We attempt to emphasize that good design produces accessible documents, thus I don't think there's a conflict. However, if the tone leans towards accessibility, I think that's to be expected from this document. Nonetheless, I will review the language of the introduction. CMN: It would seem foolish in a document about how to produce accessible content to do anything other than stress accessibility as more important than design. PS: [snip] >In addition, I think it would help if there was a more > general discussion of strategies to be employed, such as the use of > stylesheets to transform documents. I'm not sure what you mean by strategies. Could you be more specific? The prose at the beginning of section A discusses general principles (these are not exactly strategies, admittedly) and the checkpoints themselves are strategies for addressing the guidelines. Perhaps a more implementation-oriented discussion of strategies belongs in the techniques document. Any suggestions are appreciated. CMN: It may be that the techniques document should include a 'general strategies' section. The general principles are made clear in teh Guidelines document, but as Ian says implementation details belong in teh techniques document. I agree with Patrick that a brief discussion of general strategies, particularly those which will cover multiple checkpoints, would be useful. PS: [snip] > I think it would be worth mentioning up front that in some cases the best > approach will be to author an alternate page. Various guidelines mention > this, but especially as relates to media-rich content, I think it worthwhile > to acknowledge that effective design for the different audiences often > requires alternate documents. IJ: The Working Group has strong reservations about making such a statement because of the difficulties raised by alternative pages (see the Note after the checkpoints in Guideline 13). Furthermore, the Working Group feels that the checkpoint about alternative pages (13.5) should be listed *after* the others of that guideline despite the fact that it is a priority 1 checkpoint in order to dissuade authors from using this solution as a first option. Authors should attempt to make their pages accessible, not separate but equal. CMN: Often media-rich documents can be written in a manner which includes, within the one document, multiple presentations of information or function. This is the case with the incorporation of Multimedia via OBJECT in HTML, and with the use of SMIL, to name two examples. In other cases, such as Mathematics, and hopefully Vector Graphics, languages are used which encode the information in a way which makes it readily amenable to presentation through a variety of media. As a general principle it seems better to me that we support such standards rather than a number of individual, 'separate but equal' pages. When there is a widely implemented means of linking the various alternatives so they can be addressed as a single resource it may be possible to achieve more efficient transfer, but the primary concern for accessibility is keeping equivalent representations together, and in a single document is generally the best way to do this. PS: > The > three requirements for claims of conformance are pretty vague - where should > these items be noted? In comments? In some meta-element? In a separate > document? IJ: Eric Hansen has sent some interesting suggestions [1] about the conformance section that the Working Group has not yet had the opportunity to review. I trust that some of your questions will be addressed during that review. [1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0295.html CMN: I don't see any need for the document to specify where a claim to conformance might be. any or all of the above suggestions could be used, as well as in the contract which commissions a website design, on the poster used to advertise information, and anywhere people would like to make a statement about the accessibility of their website, making reference to WCAG. [snip] PS: > section: Guidelines > > * The intro to this section introduces the notion of transformation of > documents. This is a change from the tone of the intro. Perhaps an > additional section on strategies/mechanisms for transformation of documents > would help to explain the underpinnings of the approaches. If the > assumption is that stylesheets will be the basis for much of the > accessibility guidelines, then that should be stated. IJ: It is interesting that you are associating the term "transformation" so strongly with "style sheets". Does that connection come from an XSL perspective? Style sheets provide some of the solutions listed in the guidelines, but others rely on proper use of markup, organization of content and of an entire site, navigation tools, etc. CMN: The transfomration referred to is that which is caused by the rendering of the document in different device types - a TV and a braille display cannot render the same object. Information, in being rendered as an object or series of objects, undergoes some or all of one possible set of transformations to be rendered on TV and some or all of a different set of posible transformations to be rendered by a braille display. [snip] PS: > * Checkpoint 1.2 - this should perhaps be qualified to describe > programmatic elements that have a direct visual representation. Some objects > are added to extend the functionality of the page, but do not have any > specific associated visual element (they may manipulate the DOM for various > elements). The alternates should concentrate on the presentation, rather > than on code that may play a part in presenting the information. IJ: Proposed change to 1.2: Provide text equivalents for all applets and other programmatic objects that present visual information. CMN: I disagree. Where a script or applet provides a functionality, that is dealt with in other sections of the document - especially checkpoints 8.3, 8.5, and 10.1. The checkpoint here may be redundant, as it essentially refers to information presented by the object (also covered by 8.3). Restricting it to visually represented information is a mistake - first because it may be an audio object, and second because the notion of text equivalent explicitly includes the possibility of rendering nothing. PS: > * For media rich pages, some additional guidelines seem appropriate to > cover how audio should layer, especially when it is used for accessibility. > If music is playing on the page, how should this interact with an audio > alternative to a movie or animation? How should audio cues added to buttons > add to this? How do screen readers manage all the audio? I know that I am > ignorant of what is available, but I think that especially in the area of > multimedia, some more guidance would probably be useful. How does a screen > reader deal with text that interactively "pops up" somewhere as an > alternative to some graphic effect? Perhaps I just need to understand better > how screen readers are used... IJ: These subjects are discussed in section 2.9 of the Techniques Document. However, we will look further into a discussion of CSS2's aural cascading style sheets and how they can control cueing, background sounds, etc. The editors will also look into more information about synchronization and SMIL. CMN: These seem to be problems which are strictly in the domain of User Agents. PS: > * Guideline 5 seems to be in conflict with the goal of supporting > users with downlevel browsers. Several of the practices recommended against > are used because they are the most portable means of specifying a formatting > effect. Not much we can do here, except note the conflict (as is done in > the techniques doc). IJ: Yes, the conflict must be clearly documented. We will also re-examine checkpoint 13.1, which says to use the latest W3C technologies. The phrase "wherever possible" must be clarified. It may be more appropriate to use CSS1 features, for example, than some CSS2 features until CSS2 is more widely supported. It is crucial for authors to ensure that whatever features they use transform gracefully, and style sheets are designed to do so. CMN: Some practices used as a way of providing a formatting effect for down-level browsers cause accessibility problems. Unless the formatting is itself crucial to the accessibility of the document, it needs to be sacrificed if the ultimate goal is accessibility. Which it is in this case. Particularly where the techniques used are abuses of the specified semantics of the language, I think that it qualifies as a benefit accessibility can provide to everyone that documents become better structured, and the standard is better implemented. PS: > * Guideline 5.6 says "Use relative rather than absolute units in > markup language attribute values ..." and then the techniques document says > in the layout section below "Layout, positioning, layering, and alignment > should be done through style sheets (notably by using CSS floats and > absolute positioning)". Guideline 5.6 should perhaps be clarified to except > positioning attributes. IJ: As confusing as it may sound, CSS allows you to use relative units in absolute positioning (and you should). Thus, you may position an image to be offset by "3em" from the top of its containing element. This is a fixed distance, but is relative to the current font size, so it scales nicely. Thus, relative "units" should be used wherever possible. Thank you for your comments, - Ian Jacobs and Wendy Chisholm -- Ian Jacobs (jacobs@w3.org) Tel/Fax: (212) 684-1814 http://www.w3.org/People/Jacobs CMN: I second the vote of thanks. Charles --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://www.w3.org/People/Charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Friday, 12 March 1999 18:18:17 UTC