- From: Madeleine Rothberg <Madeleine_Rothberg@wgbh.org>
- Date: 5 Aug 1999 17:14:45 +0000
- To: w3c-wai-ua@w3.org
Here are some comments on the working draft, both typographic and substantive. Referring to document at: http://www.w3.org/WAI/UA/WAI-USERAGENT-19990716 My comments marked by MR:. -Madeleine MR: General comments: I support the suggestion that we arrange the guidelines in roughly order of importance. I would vote to place 11 and 12 (W3C technologies and OS conventions) nearer the top and 6 (document styles), 9 (orientation) and 10 (notify of changes) toward the end, for example. But 1 and 2 probably belong in sequence, despite any difference in importance, and there may be other logical orders that should be preserved. MR: In section 1.1 on principles of accessible design it says that the guidelines fall into 4 categories (access to interface, access to content, orientation, and system standards) but those categories are not tied to specific guidelines. Would it make sense to do that? Could be either by grouping the guidelines in four groups, or by listing in section 1.1 which guidelines support which principle. If we did organize the guidelines by those categories, we'd lose the "order of importance" option, for the most part. Abstract Some browsers or multimedia tools may not support some of the features described in the guidelines. In particular, new features of HTML 4.0 or CSS 1 or CSS 2 may not be supported. MR: Is this leftover from the WCAG document? For UA we want to encourage support of these new features, so this sentence seems out of place. 2. How the Guidelines are Organized The checkpoint definitions in each guideline explain how the guideline applies in typical content development scenarios. MR: this probably came from the WCAG document? How about: The checkpoint definitions in each guideline explain how the guideline applies in typical user agent usage scenarios. (bullet) A link to a section of the Techniques Document ([UA-TECHNIQUES]) where implementations and examples of the checkpoint are discussed. MR: Actually, it's a link to an index that then refers you to the section where the implementations and examples are discussed. I had trouble figuring this out. I kept thinking that these techniques hadn't been written yet, not realizing I had to follow a second link to the "refer to" section. I see now how this was done, and that it is also what was done for WCAG, but I think it could be clearer. MR: Was the index built to support cases where a checkpoint is related to more than one part of the techniques? Currently only 4 of the checkpoints have more than one reference, making this link to the index an annoyance rather than a help in most cases. (Though I understand that may change as the techniques document matures.) Or is the index needed so that the Guidelines doc can be stable while the techniques doc changes? In that case, let's just clarify the language. Perhaps in the Techniques index we could change the words "Refer to" to "Techniques are in section." And in the bulleted item in the Guidelines document, should we mention this index? Guideline 1 rationale on input and output device independence MR: My understanding is that most alternative input devices use either the keyboard or the mouse input channels to communicate with the operating system. I suggest adding a sentence that says something like this and urges UAs to use only the OS standard ways of reading the input channels. This might clarify the statement that UAs need not support every input device since they will most likely do so transparently by appropriately supporting the standard devices. This might sound like a technique, but I think it is important to include this info for developers who might be surprised by the long list of alternate input devices. (This is closely related to the Guideline 2 rationale, but since most readers will read GL 1 first, can we clarify here?) MR: Could add a sentence after the example of input about output device independence such as: "And any output provided in audio should also be available in text since most alternative output mechanisms rely on the presence of system-drawn text on the screen." Checkpoint 2.6 Indicate the keyboard access method to activate a user agent function using platform conventions. [Priority 2] JRG: Does checkpoint 2.6 currently only refer to how to activate an author supplied ACCESSKEY binding to a link or a control? If it is only related to ACCESSKEY, then maybe it should be stated for ACCESSKEY in the checkpoint. Otherwise I am not sure how it is different from checkpoints 2.2 and 2.3 MR: I understood this to refer to UA interface functionality, like menus and dialog boxes, and to mean "Underline the quick access letter on Windows, and do whatever the current platform usually does in other platforms." Perhaps an example note would clarify, or the technique will once it is written. Checkpoint 3.1 Ensure that all product documentation conforms to the Web Content Accessibility Guidelines. [Priority 1] MR: Should this say "all electronic product documentation"? The technique goes as far as "Documentation created in HTML" but the checkpoint wording seems to include paper as well, which the WCAG won't have much help for. The WCAG has basic principles which apply to non-HTML docs, so maybe techniques should say "Use WCAG for docs in HTML, and observe the same principles as well as relevant interface checkpoints in this document when using other technologies." Guideline 5: User agents are only expected to provide this control for content that it recognizes. MR: Should be "that they recognize." (bullet) The document's content. This means whether primary content or alternative representations of content or both are rendered. MR: for consistency with previous bullet, change to: The document's content: whether primary content or alternative representations of content or both are rendered. Otherwise, users who are blind, have visual impairments, some types of learning disabilities, or any user who cannot or has chosen not to view the primary representation of information will not know content of the information on the page. MR: suggest minor edits to: Otherwise, users who are blind, have visual impairments, or have some types of learning disabilities, or any user who cannot or has chosen not to view the primary representation of information, will not know the content of the information on the page. MR: I propose adding a new checkpoint (between current 5.5 and 5.6) "Allow the user to turn on and off rendering of audio descriptions. [Priority 1]" Guideline 6: Ensure that the user has control over the colors, fonts and other stylistic aspects of a document and can author styles and user agent default styles. MR: Add the word "override" before "author styles." (It would also be nice if the UA supported the user authoring styles. But I think that comes in the configuration checkpoints (smile).) Checkpoint 6.8 Allow the user to control video frame rates. [Priority 1] MR: Apologies if I missed discussion on this (can't find any in this year's mailing list archives). Why do users want to control video frame rates? If what is meant is that users want to speed up and slow down video to improve comprehension or save time, say that. Changing frame rate changes the quality of video but may not effect how fast content goes by. The only access issue I'm aware of for frame rates is that sign language requires high frame rates to be comprehensible, but that is an authoring issue and a bandwidth issue, I think. Checkpoint 7.6: If a technology allows for more than one caption or description track for audio, allow the user to choose from among tracks. and Checkpoint 7.7 Allow the user to specify that captions for audio be rendered at the same time as the audio. MR: Remove "or description" from 7.6. Audio tracks do not get description tracks. Also, I suggest swapping the order of 7.7 and 7.6, since rendering at the same time is the most basic thing to be done, and switching tracks is an add-on. (I do think it is priority 1, just slightly below getting the synchronization right.) Checkpoint 7.8 If a technology allows for more than one caption or description track (e.g., text, video of sign language, etc.) for video, allow the user to choose from among tracks. and Checkpoint 7.9 If a technology allows for more than one audio track for video, allow the user to choose from among tracks. MR: I'm not clear on the difference between these two. If the intent was to separate captioning checkpoints from description checkpoints, remove "or description" from 7.8 and perhaps add "or video" to cover the idea of ASL tracks. Then clarify that the audio tracks referred to in 7.9 may be description. MR: Or is 7.9 meant to refer to alternate languages, or some other kind of non-description alternate audio like director's comments? If so, is that an access issue? (That is, if the UA supports changing languages or hearing the director's comments, that feature must be accessible, but that should be covered by the checkpoints on interface accessibility.) Checkpoint 7.10 Allow the user to specify that text descriptions of video be rendered at the same time as the video. [Priority 1] and Checkpoint 7.11 Allow the user to specify that auditory descriptions of video be rendered at the same time as the video. MR: Could 7.10 and 7.11 be combined with "and" or "or" ("text and auditory descriptions")? Also, as mentioned for 7.6 and 7.7, I suggest reordering so that the checkpoints on rendering at the same time (7.10 and 7.11) come before the ones on extra tracks (7.8 and 7.9). Guideline 12: When a user agent communicates with other software (dependent user agents, the operating system, plug-ins), must do so through applicable interfaces. MR: add "it" before "must." Checkpoint 12.4 For desktop graphical browsers. Comply with W3C Document Object Model specifications and export interfaces defined by those specifications. MR: Should this be part of Guideline 11 on W3C technologies rather than in this section on operating system conventions? Or is it here because we are asking that UAs export the DOM into an operating system standard interface? If so that could be clearer. Techniques document 2.1 Examples and Deprecated Examples This document contains a number of examples that illustrate accessible solutions in HTML, CSS, etc. but also deprecated examples that illustrate what content developers should not do. MR: Left over from WCAG? There aren't currently any deprecated examples in the techniques, though I know it isn't done yet. At any rate, they won't be illustrations for content developers. 3.8.1 These profiles can serve as models and may be copied and fine-tuned to mean an individual's particular needs. MR: change "mean" to "meet." 3.9.2 Accessing documentation in familiar applications is particularly important to users with disabilities who must learn the functionalities of their tools, be able to configure them for their needs, and to be compatible with assistive technology. MR: suggest change to: Accessing documentation in familiar applications is particularly important to users with disabilities who must learn the functionalities of their tools and be able to configure them for their needs. Commonly used applications are also more likely to be compatible with assistive technology. Documents in alternative format documents can be created by agencies such as Recording for the Blind and Dyslexic and the National Braille Press. MR: Remove second "documents", change "format" to "formats." Or start sentence with "Alternative." User instructions should be created in an input device-independent manner. MR: suggest changing "created" to "worded" or "expressed." 4.4 The document object model MR: The current technique text talks more about what DOM can't do than about what it can do. Would be helpful to have concrete examples of useful DOM features. Unfortunately I don't know enough about DOM to suggest them myself. The text about what DOM can't do could possibly say, "The DOM can't do some things, therefore see the techniques in the sections on user interface to ensure style and scripting controls are accessible" rather than insert info on accessible controls in this section. Section 7 SMIL accessibility MR: I can work on techniques for multimedia accessibility sections. One question is, can the UA techniques document be more forward looking than current W3C recommendations? The SMIL access note being written by EO refers only to SMIL 1.0, but SMIL 2.0 is in development and may include additional features. Can we use the UA recommendations to encourage player developers to advance the state of the art? MR: If section 7 will primarily point to the SMIL access document, which sections would be best for specific techniques? 3.3, User Control of Style? 3.3.1 Feature Control? MR: Also, should we discuss techniques for other streaming media types (AVI, QuickTime)? NCAM has lots of info on this stuff so if you give me some pointers on how you'd like it structured I can pull something together for the group to look at. Section 9, part on Example Technique: Java's Direct Access In Java 1.1.x, Sun's Java access utilities load an assistive by monitoring the Java awt.properties file for the presence of assistive technologies and loads them as shown in the folowing code example: MR: typo, should be "following." --end of MR comments--
Received on Thursday, 5 August 1999 17:13:18 UTC