- From: Judy Brewer <jbrewer@w3.org>
- Date: Wed, 23 Feb 2005 09:57:05 -0500
- To: w3c-wai-au@w3.org
Dear AUWG Participants, Please find, below, comments compiled from several EOWG discussions of your 22 November 2005 ATAG 2.0 Last Call Working Draft: http://www.w3.org/TR/2004/WD-ATAG20-20041122/ for which the Call for Review is available at: http://lists.w3.org/Archives/Public/w3c-wai-ig/2004OctDec/0221.html Our comments are divided into three sections: comments on (A) the introduction, (B) the guidelines, and (C) the glossary. Please see the explanatory note at the beginning of the glossary comments section. I apologize for the delay in transmitting these comments to your WG. I'd previously given Jutta and Matt a link to EOWG's draft comments under discussion, so they should already be familiar with the general content. If you need clarification of any of our comments, please let us know. In particular, Shawn hopes to follow up with your group on several of the comments. Thank you for the opportunity to comment. Regards, - Judy Brewer, on behalf of EOWG ------- EOWG Comments on ATAG 1.0 Last Call Working Draft, 22 November 2005 A. Comments on ATAG 2.0 LCWD Introduction: In general: - Build more plain-language clarification into the first few paragraphs of the Introduction, so that readers have more of an idea what ATAG is within the first few sentences of the Introduction. Right now the first sentence seems fairly abstract and does not give a clear idea of what the document is. ("This document specifies requirements that, if satisfied by authoring tool developers, will lower barriers to accessibility"... also, in the abstract, "This specification provides guidelines for designing authoring tools that lower barriers to Web accessibility for people with disabilities.") - Check for understandability of the writing throughout the whole Introduction section, particularly focusing on the sequence of what is stated, and where it's explained. Right now these do not seem to flow clearly. - This ATAG document doesn't seem to sufficiently differentiate itself from WCAG, even though there is a section addressing this. - The status section is very long. There is some redundant information, and some information that seems more appropriate for an Introduction than for a Status section. Here are some specific suggestions for how to address this: ...Delete all material between 1.4 and 1.4.1 and refer instead to http://www.w3.org/WAI/intro/components. ...Leave section 1.4.1 (with any relevant, non-redundant material from the paragraph 2 before that section) ...Leave section 1.4.2 (with any relevant, non-redundant material from the paragraph right before section 1.4.1) ...Refer to Components Documents for XAG background, instead of explaining it here since XAG is not yet stable. ...For 1.3, consider adding a much more direct and relevant statement: Authoring tools should be designed so that everyone can create Web content. [or] Authoring tools should be accessible to people with disabilities. ....There appears to be a recursive link at "authoring interface checkpoints relative to ISO...". - Priorities: We are wondering if it's unnecessarily complex. It is hard to understand what the consequences of the different categories of priorities are; it seems that it would help if these are linked back to the practical meaning. Alternatively, maybe this section is necessarily complex, but needs more of an introduction to the terminology before getting into the explanation. (For example, the graphic uses terms before they are introduced in the text, which is confusing.) Several people commented that the regular vs. relative terminology is helpful, and perhaps should even be used more, but should be defined earlier. We don't have specific a specific suggestion on how to rewrite the priorities section, but we'd like to offer to work with you on it. B. Comments on ATAG 2.0 Guidelines ---------------------------------------------- Guideline 1: "Make the authoring interface accessible": In the first descriptive paragraph, the last sentence is long and unnecessarily difficult; consider breaking it up. Consider describing 1.2, 1.3, 1.4 and 1.5 individually. Compare this to the first descriptive paragraph for Guideline 2; that paragraph briefly describes every part 2.1-2.4. Perhaps an overall rationale needs to be stated explicitly; for instance, "Rationale - If an authoring feature is present for one user population then a functionally equivalent feature should be present for all users." Guideline 1.2: "Ensure that the authoring interface enables accessible editing of element and object properties": The term "element" is ambiguous in its definition or usage here. Following the link to definition of element reveals the term is used in two ways: (1) to denote a general token in the programming language sense and (2) to denote the actual grammar symbol, element, from markup languages HTML and XML. Also, please examine whether this is the term really needed. Guideline 1.4 "Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits": The rationale needs more explanation in order not to be interpreted as a requirement for a general usability feature. For instance, explaining why this is essential for authors with certain types of disabilities would be helpful. Guideline 4: "Promote and integrate accessibility solutions": Guidelines 4.1 - 4.4 are relatively easy to read and understand, but it is difficult to reconcile their description and meaning with the general introductory paragraphs for Guideline 4. The first sentence in particular is difficult to parse: "This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document." Introductory comments for the main guidelines 1, 2, 3 and 4: The introductory comments for the main guidelines should include links to any terms that are defined in the glossary. For example, in Guideline 2, the overall introduction should provide links to the terms such as "unrecognized markup," "accessible information," "transformations," "conversions," etc. Any defined term occurring in the document link should to the definition the first time it occurs. Guideline 2.1, "Support formats that enable the creation of Web content that conforms to WCAG": Even after considerable discussion, and following the link to the definition, we were not entirely clear what is meant by "format" here. For instance, we were wondering whether it was related to markup languages, or to doc type schemas, or something else. Please clarify here and then reinforce that in the glossary. Success Criteria: In the success criterium, the terminology "must always conform" seems awkward. Why not just say "conforms"? e.g.: Current: "At least one full-featured Web-based authoring interface must always conform to WCAG." Suggested replacement: "At least one full-featured Web-based authoring interface conforms to WCAG." If concerned about "always", could put that in the preface text. C. Comments on ATAG 2.0 Glossary -------------------------------------------- Explanation of the following comments: The EOWG has set up a "Lexicon Task Force" that is developing a "Beginners' Lexicon for WAI Documents". This will be short lexicon with definitions in clear and simple language and contextualized to Web accessibility. The primary purpose of this beginners' lexicon is to assist translators of WAI documents, though it also may be helpful to people new to Web accessibility. The following definitions are ones where we would be likely to change them slightly or significantly from what is in the glossary section of your current draft, as shown below, when incorporating them in the Beginner's Lexicon for WAI Documents. We invite you to examine these definitions for two reasons: to see if you disagree with any of our re-statements of your definitions, and to consider whether any of the following definitions would be more suitable for use within the ATAG 2.0 glossary than the definitions currently present. More background on the Lexicon Task Force is available below [1]. - Accessible Web content Accessible Web content is sufficiently free of accessibility problems to be usable by everyone regardless of disability or environment. - Attribute Information that explains, identifies or modifies an element in a markup language. Element types may have more than one attribute, like 'class', 'title', 'width' and 'height'. Some attributes are integral to the accessibility of content (for example, the 'alt', 'title', and 'longdesc' attributes in HTML) - Audio Descriptions Audio description (also called "Described Video") is an equivalent alternative that provides aural information about actions, body language, graphics, and scene changes in a video. Audio descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An audio description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The audio description must be synchronized with the auditory track of a video presentation, usually during natural pauses in the auditory track. - Authoring Tool Any software or service that is used to produce content for publishing on the Web. Authoring tools include Web content editors, document conversion tools, and software that generates Web content from databases. - Captions Captions are equivalent alternatives that consist of a text transcript of the auditory track of a movie (or other video presentation) and that is synchronized with the video and auditory tracks. Captions are generally rendered graphically. They benefit people who are deaf or hard-of-hearing, and anyone who cannot hear the audio (for example, someone in a noisy environment). - Conversion A conversion is a process that takes, as input, content in one format and produces, as output, content in another format (for example, "Save as HTML" functions). - Device independence The use of a webpage or event handler with any kind of input device. Scripting should be device-independent or provide multiple input and output options for different devices. For example, onDblClick requires a mouse; there is no keyboard equivalent for double clicking. Input devices may include pointing devices (such as the mouse), keyboards, Braille devices, head wands, microphones, and others. - Equivalent Alternative An equivalent alternative is content that is an acceptable substitute for other content that an end-user may not be able to access. An equivalent alternative fulfils essentially the same function or purpose as the original content upon presentation to the end-user. Equivalent alternatives include text alternatives, which present a text version of the information conveyed in non-text content such as graphics and audio clips. Equivalent alternatives also include "media alternatives", which present essential audio information visually (captions) and essential video information auditorily (audio descriptions). - Markup language A markup language is a syntax and/or set of rules to manage content and structure of a document or object (for example, HTML , SVG , or MathML). - Repairing, Accessibility Accessibility repairing is the process by which Web content accessibility problems that have been identified within Web content are resolved. ATAG 2.0 identifies three categories of repair: Automated (that is, the authoring tool is able to make repairs automatically, with no author input required), Semi-Automated (that is, the authoring tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete) and Manual (that is, the authoring tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial way). - Techniques Techniques are informative suggestions and examples for ways in which the success criteria of a checkpoint might be satisfied and implemented. - Transcript A transcript is an equivalent text alternative for the sounds, narration, and dialogue in an audio clip or an auditory track of a multimedia presentation. For a video, the transcript can also include the description of actions, body language, graphics, and scene changes of the visual track. - User Agent Software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software. [1] Info on EO Lexicon Task Force: - First draft of a Lexicon overview: http://www.w3.org/WAI/lexicon/Overview.html - Lexicon requirements document: http://www.w3.org/WAI/EO/changelogs/cl-lexicon - Lexicon Task Force Work Statement: http://www.w3.org/WAI/EO/2004/lexicon.html - Lexicon list archives: http://lists.w3.org/Archives/Public/public-wai-eo-lexicon -- Judy Brewer +1.617.258.9741 http://www.w3.org/WAI Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C) MIT/CSAIL Building 32-G530 32 Vassar Street Cambridge, MA, 02139, USA
Received on Wednesday, 23 February 2005 14:56:42 UTC