- From: Hansen, Eric <ehansen@ets.org>
- Date: Tue, 25 Apr 2000 11:20:32 -0400
- To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
Date: 25 April 2000, 11:15 hrs To: UA List (w3c-wai-ua@w3.org) From: Eric Hansen Re: Comments on 10 March Version of the UA Techniques Document This memo documents some comments regarding the 10 March 2000 version of the UA Techniques document. Many of the comments also apply to the UA Guidelines document. The hardcopy for a bunch of small edits is being mailed to Ian Jacobs and Jon Gunderson. Most, if not all of these comments are, I believe, editorial in nature. 1. Clarify the need for outputting the entire content through at least three modalities -- visually-displayed text, synthesized speech, and Braille. It seems to me that the document needs to make clearer that a UAAG-compliant User Agent that is accessing WCAG-compliant content will be able to render all Web content through each of at least three modalities -- visually-displayed text, synthesized speech, and Braille -- subject, of course, to the limitations the applicability provisions of UAAG. Checkpoint 1.1 requires that every functionality available through the user interface also be available through every _input_ device API supported by the user agent (emphasis added). But what about "_output_ modalities? I can understand that one may not want to require that all content be available from _each_ output _device_ (speakers, beep-producing device, etc.). Technically speaking, perhaps what is needed is already covered by checkpoint 1.2 ("Use the standard input and output device APIs of the operating system." [Priority 1]). But the necessity of having all content available in each of the three channels seems to be underemphasized. I think that should be added somewhere. 2. Provide better descriptions of visuals. I believe visuals need to be better described. With the possible exception of one visual (in Technique for checkpoint 8.6), I don't think we can say that we are providing true text equivalents. Consider the following example. OLD: Prose description in main body of document: "The following image shows how Opera [OPERA] allows the user to configure link rendering, including the identification of visited links." The alt-text, which shows up in the ToolTips window says: "The Opera dialog box for configuring links" NEW: "Opera [OPERA] allows the user to configure link rendering. For example, as shown in the image below, Opera provides a "Link Presentation" dialog box that allows the user to configure attributes, such as how unvisited links should be rendered (e.g., by underline, strike through, color) and how long visited links will be marked as visited before reverting to an unvisited status." I suppose that the current alt-text is OK, provided that the primary text mentions the dialog box (along the lines suggested above). Rationale: The picture is supposed to show "_how_ Opera allow the user to configure link rendering". The minimal explanation of "how" must, at a minimum, make reference to the "dialog box". Thus, if the "text equivalent" does not mention the dialog box and say something useful about it, I don't think that it can be considered a true text equivalent. Virtually every image in the document needs a similar expansion. I believe that to fail to do so would mislead people about what a text equivalent is. 3. Fix the definition of "Viewports". Fix reference to content. Menus and message should not be excluded from the definition of "content". Old: "Views, viewports, and current viewport User agents may handle different types of content: a markup language, sound, video, etc. The user views rendered content through a viewport, which may be a window, a frame, a piece of paper, a speaker, a virtual magnifying glass, etc. A viewport may contain another viewport (e.g., nested frames). Viewports do not include user interface controls that do not present content, such as prompts, menus, alerts, etc. User agents may render the same content in a variety of ways; each rendering is called a view. For instance, a user agent may allow users to view an entire document or just a list of the document's headers. These are two different views of the document. The view corresponds to how source information is rendered and the viewport is where it is rendered. The viewport that contains both the current focus and the current selection is called the current viewport. The current viewport is generally highlighted when several viewports co-exist. A viewport may not give users access to all rendered content at once. In this case, the user agent should provide a scrolling mechanism or advance and rewind mechanism." New: "Views, viewports, and current viewport User agents may handle different types of content: a markup language, sound, video, etc. The user views rendered content through a viewport, which may be a window, a frame, a piece of paper, a speaker, a virtual magnifying glass, etc. A viewport may contain another viewport (e.g., nested frames). <CHANGE>Viewports do not include user interface controls such as prompts, menus, alerts, etc.</CHANGE> User agents may render the same content in a variety of ways; each rendering is called a view. For instance, a user agent may allow users to view an entire document or just a list of the document's headers. These are two different views of the document. The view corresponds to how source information is rendered and the viewport is where it is rendered. The viewport that contains both the current focus and the current selection is called the current viewport. The current viewport is generally highlighted when several viewports co-exist. A viewport may not give users access to all rendered content at once. In this case, the user agent should provide a scrolling mechanism or advance and rewind mechanism." 4. Use plain English rather than short symbolic titles when referring to documents. For the example in section 1.1 of the document, it reads: "... link to the checkpoint in [UAAG10]." Instead it should read something like: "... link to the checkpoint in the User Agent Accessibility Guidelines 1.0 [UAAG10]." 5. Make Technique statements parallel in construction. For example, all Techniques within a checkpoint start should have a similar construction, such as by starting with a verb. 6. Respect proprietary rights of regarding product and company names. For example, the document often uses the term "Windows" without referring to Microsoft Windows. The document refers to Java without mentioning Sun. Carefully distinguish between W3C DOM and just a generic DOM. Make sure the term "zip" is generic or credit the owner. I think that W3C needs a policy for referring to products and then the documents need to follow the policy. 7. Widen margins in text boxes. Text within text boxes need wider margins. The text is too close to the lines. 8. Fix dash problem. For dashes that cannot be put into dash characters, use double hyphens in preference to single hyphens. 9. Fix checkpoint 1.5. I am unsure whether checkpoint 1.5 is needed in its present form. It seems covered by other checkpoints. Also, the techniques seem to be imprecise about whether the text equivalent that must be provided refers only to visually-displayed text or to other renderings as well (Braille and synthesized speech). Sometimes in this checkpoint, the term text equivalent seems to be referring to unrendered content and other times to rendered content, in which case it may be important to make clear what renderings are intended. The following attempts to clarify, though it seems as yet imperfect. Also I am not sure why it is limited to "messages". Why not all content? Old: "1.5 Ensure every non-text message (e.g., prompt, alert, etc.) available through the user interface also has a text equivalent in the user interface. [Priority 1] (Checkpoint 1.5) Note. For example, if the user interface provides access to a functionality through a graphical button, ensure that the user interface also provides access to the same functionality through a control that includes a text equivalent. If a sound is used to notify the user of an event, announce the event in text on the status bar as well. Refer also to checkpoint 5.7. Techniques: Display text messages on the status bar of the user interface. For graphical user interface elements such as proportional scroll bars, provide a text equivalent (e.g., a percentage of the document viewed). Provide a text equivalent for beeps or flashes that are used to convey information. Provide a text equivalent for audio user agent tutorials. Tutorials that use speech to guide a user through the operation of the user agent should also be available at the same time as graphical representations. All user interface components that convey important information using sound should also provide alternate, parallel visual representation of the information for individuals who are deaf, hard of hearing, or operating the user agent in a noisy or silent environment where the use of sound is not practical. Text equivalents of messages are important for deaf-blind users who cannot use audio or graphical cues and who rely on Braille." New: "1.5 Ensure every non-text element available through the user interface also has a text equivalent in the user interface. [Priority 1] (Checkpoint 1.5) Note. For example, if the user interface provides access to a functionality through a graphical button, ensure that the user interface also provides access to the same functionality through a control that includes a text equivalent <CHANGE>_that can be displayed visually, as synthesized speech, or as Braille.</CHANGE>_ If a sound is used to notify the user of an event, announce the event in text on the status bar as well. Refer also to checkpoint 5.7. Techniques: Display text messages <CHANGE>visually on the status bar of the user interface. For graphical user interface elements such as proportional scroll bars, provide a text equivalent (renderable visually, as synthesized speech, and braille) (e.g., a percentage of the document viewed). For beeps or flashes provide a text equivalent that can be rendered as Braille, synthesized speech, or visually-displayed text). Provide a text equivalent for audio user agent tutorials. Tutorials that use speech to guide a user through the operation of the user agent should also be available at the same time as graphical representations. {*** Note that "tutorials" are certainly more than "messages". ***} For user interface components that convey important information using sound, also provide alternate, parallel visual representation of the information for individuals who are deaf, hard of hearing, or operating the user agent in a noisy or silent environment where the use of sound is not practical. Provide Braille renderings of text equivalents for deaf-blind users who cannot use audio or graphical cues and who rely on Braille. </CHANGE> ==== 10. Clarify the meaning of user interface. I find the meaning of the term "user interface" somewhat ambiguous. I am not sure that I fully understand or agree with the distinction between "user agent user interface" (i.e., the controls and mechanisms offered by the user agent for user interaction, such as menus, buttons, keyboard access, etc.) and the "content user interface" (the "content user interface", i.e., the active elements that are part of content, such as form controls, links, applets, etc. that are implemented natively). I am not sure that there is anything wrong with the current definition. It seems, in principle, open to all kinds of output devices (including Braille, etc.) and input devices. But in actual usage in the document, the term user interface seems to incorrectly assume that content is displayed visually or as prerecorded audio but not as braille or synthesized speech. This makes the term biased, as though there could not be Braille output. I can't help but feel that our discussion about text equivalents and output of content via APIs-versus-user interface has been somewhat impaired by lack of clarity regarding the meaning of "user interface." I would be interested in seeing if a user interface might be more formally extended to relate better to other concepts in the UA document (e.g., views, primary content, unrendered-vs-rendered content, etc.). This is a bit vague and maybe there is nothing to do about it now... 11. Fix the definition of "content". Fix the definition of content. I know that some modification has been made. Hopefully, the improvements will rub off on some of the foregoing issues (user interface, viewports, checkpoint 1.5). =========================== Eric G. Hansen, Ph.D. Development Scientist Educational Testing Service ETS 12-R Princeton, NJ 08541 609-734-5615 (Voice) E-mail: ehansen@ets.org (W) 609-734-5615 (Voice) FAX 609-734-1090
Received on Tuesday, 25 April 2000 11:20:54 UTC