- From: Patrick Schmitz <pschmitz@microsoft.com>
- Date: Thu, 11 Mar 1999 16:03:22 -0800
- To: "'Philipp Hoschka'" <Philipp.Hoschka@sophia.inria.fr>, "'w3c-wai-gl@w3.org'" <w3c-wai-gl@w3.org>
- Cc: "'symm@w3.org'" <symm@w3.org>
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. Overall, I agree with Warner on the section identification. The Guidelines appear to be the first appendix, rather than the heart of the document. I would just remove the "A." from this section header. I also think that if the document will stand on its own, more background information or points should be provided. E.g. there should at least an introduction to various devices commonly used to enhance accessibility, such as screen readers. 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. Perhaps a brief discussion of the common use-cases would help: How a user with blindness typically browses the web, and the same for users with hearing, cognitive, language impairments. Many authors and designers have little or no understanding of the current state of affairs in these cases. 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. Running through the document start to end: section: Introduction * Intro section describing use of alt text as a benefit to users with blindness: This would benefit from mention of screen readers or similar technology. To the reader without experience with such devices, the notion of replacing an image with text to help users with blindness seems curious at best. * Following point mentions use of altText in tooltips - this means a loss of features for designers, who often use the tooltip text as an invitation to interaction ("click here to learn more"). Guideline 15.1 says not to use this at all, and yet interaction designers often recommend doing this. * Further down, bullet "Why certain pages are inaccessible". Interesting word choice - "inaccessible" seems a bit strong and sounds like a 404 synonym. section: How the guidelines are organized * What exactly is the point of the section on "Conformance"? 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? * Why is the section on "Conformance" in a section on document organization? 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. Some additional verbiage about or references to typical accessories that are used to enhance accessibility (such as screen readers) would probably help many designers who are less familiar with these issues (the link to the Braille display definition is a good example). * 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. * 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... * 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). * 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. Thanks - Patrick Patrick Schmitz Program Manager - HTML+TIME Microsoft
Received on Thursday, 11 March 1999 19:03:28 UTC