- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Wed, 8 Mar 2006 07:31:56 -0600
- To: <w3c-wai-gl@w3.org>
- Message-ID: <000a01c642b4$c57bcfd0$ee8cfea9@NC6000BAK>
Here is the INTRODUCTION issues list and proposed dispositions based on proposed new introduction ATTACHED IS THE NEW INTRODUCTION Issue List Tue Mar 7 01:27:34 CST 2006 _____ 25 issues found. ID Summary 367 Include a section on development process Consider inserting a section on development process: Choice of technology and impact on accessibility. This section should talk about "widely available", time lag before assistive tech adopts the technology, availability of AT in natural language of site, backword compatibility, etc. This section may be placed before the guidelines and checkpoints are listed. CLOSE with comment - We are unable to go into that kind of detail in a standard. We are encouraged to keep the intro as short as possible. 392 Better definition of "audience" I want a better definition of the audience. For a writing project of this kind of scope, audiences must be defined clearly and explicitly, as well as how those audiences will use this document. CLOSE with comment - We are unable to go into that kind of detail in a standard. We are encouraged to keep the intro as short as possible. Further information on audience is contained in support documents such as the WCAG 2.0 overview. 400 What is meant by "perceivable?" Guideline one needs some introductory material explaining what is meant by "perceivable". CLOSE with comment - guideline 1 is much more explicitly spelled out now - and more information is available in the Understanding WCAG 2.0 document.. 515 robust is difficult to understand Use of the word "ROBUST". Unless you were highly involved in technical circles, most individuals would not understand the implications of using the word "robust" . CLOSE with comment - We have reworded the principle to make it clearer 546 Define key terms in guidelines and make consistent The descriptions of guidelines in the "Overview of Design Principles," and the individual guidelines themselves, should be made consistent; and the key terms used for the guideline level (e.g. perceivable, robust, etc.) must be defined very clearly, in order for the document to work when translated into other languages. CLOSE with comment - We have now made them consistent. Perceivable, operable, understandable all mean what the standard dictionary definition means. We would be happy to work with translators if there is any ambiguity. . 547 Link to WAI resources instead of EOWG home page Send people to the WAI Resource page, instead of the EOWG home page, for supporting resources. CLOSE with comment - We cite both but have moved WAI to the front. 553 Goal of guideline 1 This is an excellent statement of a goal. We understand that the statement is not saying all content must be understandable by all, but that all users should at least be able to discern the information presented by a page. CLOSE THIS ISSUE. - We agree. Thanks. (It is not an issue but a statement of understanding.) 658 are examples "recommended" or "one of many possible solut... You should clarify for the reader whether the examples given are designed to be "recommended" solutions or whether they are just one of many possible solutions. CLOSE with comment - Done - examples moved to How to Meet and language added. Should be clear for techniques and examples. 825 Suggestions for front matter and introduction Mostly frontmatter instructions for Ben. Plus this comment on intro Introduction, Purpose, 1st paragraph - Remove the sentences about accessibility to a variety of Web-enabled devices. This is a benefit of accessibility but it should not be discussed in the first paragraph of the document. It can be covered later or left to EO to promote. CLOSE with comment - This has been edited to add focus on disability. 1205 include more examples that show benefit to people without... Wants examples of how this benefits people without disabilities. We might consider this as a new header in How To Meet docs. CLOSE with comment - This is not within our scope. However are considering this for a later followup activity. At that time we may add to a support doc. 1327 End users missing from audience One of the biggest audiences is not covered and that is the group who is actually served by implementation of a good set of guidelines in a successful way. It is important that the end user be given high priority in this process and its aftermath. CLOSE with comment - Added. Done. 1337 No disabled people, only disabled technology There were several look a like things I did not comment on but only made one pass at those similar. This is that there are no disabled people, there is only disabled technology. We need to reduce functional barriers, not class people. CLOSE with comment - Look at new wording in introduction. 1342 Which usability issues are included, and why The scope of the document states that "the guidelines do not include standard usability recommendations except where they have specific ramifications for accessibility beyond standard usability impacts." However, guideline 2.5 is a standard usability guideline. Maybe it would be useful to include usability experts in the discussion and come to a joint agreement on which usability-related guidelines should be covered in the WCAG and how they should be worded. CLOSE with comment - As noted in your comments, we do include usability measures where they have special disability ramifications. We have recruited usability people and have a larger number as reviewers and contributors. 1520 Conformance can't guarantee 100% accessibility These guidelines provide the basic requirements for designing accessible Web content. This document is not designed to provide the background needed to learn about accessible Web design in a thorough or effective manner for those interested in learning. Readers are therefore referred to the Education and Outreach Working Group of the Web Accessibility Initiative BUT DO NOT GUARANTEE ACCESSIBILITY FOR ALL CLOSE with comment - agree - added note to this affect to conformance section. 1557 Editorial suggestions for beginning sections * Abstract o Change ""Accessible" to a wide range of people ..." to ""Accessible" means that your web content is available to a wide range of people with disabilities, including those with blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. " DOESN'T FIT CURRENT SENTENCE STRUCTURE o Change "Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users." to "Following these guidelines will also make your Web content more usable by the vast majority of users, including older users." DONE o Change "including a wide variety of assistive technology." to "including a wide variety of assistive technologies. " DONE o Need to explain the purpose of the "Introduction to Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents". GONE * Introduction o "Web Content Accessibility Guidelines (WCAG) 2.0" should be "Web Content Accessibility Guidelines (WCAG) version 2.0." DONE * Four Principles o Suggest listing the principles after, instead of before, the discussion of the structure of the document. HYBRIDIZED THESE * Audience and Related Documents o Guide to WCAG 2.0 should link to the document DONE o Guide to WCAG 2.0 and General Techniques should define for whom they are intended as the others do. We need to differentiate these better. They sound like the same document. THEY ARE COMBINED NOW o Guide to WCAG 2.0 - the first two sentences are not complete sentences. FIXED * HTML and XHTML Techniques - last two sentences are not complete sentences. NO LONGER EXIST * The question of baseline o Much of the discussion here refers to meetings that have occurred and decisions that have been made. Will this text remain in the final document? If not, it would be better to mark it somehow as the editorial notes are marked so that it is obvious what is part of the WCAG document and what is just background information. BASELINE INFO NOW IN CONFORMANCE AND A WHITEPAPER ` CLOSE with comment - EDITS MADE EXCEPT WHERE OBE 1559 Principles, guidelines, and glossary are not normative Normative sections of WCAG 2.0 Principles and guidelines are not really normative, only the success criteria are. The second paragraph actually says this. The Glossary can't be normative because WCAG doesn't own all of the terms in it. Audience and Related Documents change "order to determine the exact wording of the guidelines and success criteria" to "order to determine the exact wording of the success criteria " - as previously stated, the principles and guidelines should not be normative. CLOSE with comment - FIXED edits.. Glossary can be normative. In fact it has to be. 1584 Need more inclusive terminology than "people with disabil... There is an overall need to improve the use of terminology relating to "people with disabilities". A more inclusive term with a higher degree of coverage is needed. Possible non-exhaustive options include "people with impairments" or "users with disabilities", "very young and elderly users, handicapped users, users with special needs"- as also referred to in most European activities CLOSE with comment - We have incorporated some of these terms in the latest draft. Generally we are trying to use consistent terminology throughout. 1. 1856 Provide definition of accessibility I would like the wcag20 specification document to provide a definition of "accessibility", in addition to the 4 necessary conditions. For 2 reasons: 1) the necessary conditions are vague in what it is mean by "each user", "understandable", "robust enough to work" 2) a definition might be based on other parameters other than perceivability, operability, understandability and robustness. <SNIP> CLOSE with comment - The working group considered this and decided to not define accessibility . 1857 add QA and reviewers to audience Add "people involved in QA or accessibility reviewers" to list of audiences for WCAG2. CLOSE with comment - DONE 1859 links to documents missing from guidelines There is no clear reference on the primary document or the navigation to some of the supporting documents, such as the Questions and Answers about Baseline http://www.w3.org/WAI/intro/wcag20-baseline.php which is only found as a link on one of the subsequent documents. CLOSE with comment - these have been added 1866 downloaded content vs web content If the suggested text "Note: If data, software or other materials are downloaded over the internet but are not used via a user agent then they are not considered Web content and are not covered by these guidelines." is included in a future draft it is hoped that care will be taken to more clearly illustrate the concept. For instance, one might assume that a spreadsheet workbook downloaded from a site and intended to be accessed by a compatible spreadsheet application is "data" and would not be covered these guidelines. It would be unfortunate if the same logic were applied to content contained in proprietary or open source formats that could - for the most part - be as easily represented in a baseline technology. Without guidance, it might be possible to argue that the content of a downloadable document is "data" for a word processing application or a document viewing application. Is the distinction drawn between application software and user agent sufficient to forestall such sophistry? If it is not, then it should be. CLOSE with comment - We have decided to not put the topic in question into the WCAG Document 1867 web applications vs desktop applications The following proposed Note introduces a grey area: "Note: If data, software or other materials are downloaded over the internet but are not used via a user agent then they are not considered Web content and are not covered by these guidelines." The intent seems to be to exclude things like Office Automation (OA) applications from being defined as user agents, but in the Glossary, a user agent is defined as any software that retrieves and renders Web content for users. Microsoft Word, for example, does this, especially but not exclusively if the content is in MS-Word format, and admittedly through integration with Internet Explorer. It also acts like a helper application for IE when you are on an HTML page and activate a link to a Word document. So it's not clear whether it is a user agent or not. CLOSE with comment - We have decided to not put the topic in question into the WCAG Document Keep the following two open til we finish up the baseline doc 1701 potential confusion in baseline examples 2 and 3 I realize these two examples are informative, but they have the potential to create confusion through multiple interpretations. Example 2 "...supported by more than one accessible and affordable user agent for more than one release." The word release is a relative term. Release cycles vary greatly for different software. Does this include major and/or minor releases (e.g. feature release vs a bug fix release). What about where only one accessible user agent exists, like Internet Explorer was for the longest time. Use words like "readily available user agent" rather than "more than one." The words "readily available" could also remove multiple interpretation of the word "release". A definition of the phrase "readily available" could be added to the glossary, with a definition something like "...with minimal effort is attainable by searching the Internet." Example 3 "... to reflect the increased ability of affordable user agent (including assistive technology)..." I might ask "are there affordable assistive technologies?" thinking about the current cost of screen readers. The affordability of assistive technologies is relative to a person's income, or the availability of funding to them (in Canada funding is available every five years), so this leaves room for many different interpretations. Perhaps replace "affordable" with "readily available." 1797 Add SC to select appropriate baseline There are important reasons why WCAG 2.0 should not establish a baseline or set of baselines. (rationale given in Bugzilla) Suggested criteria that must be taken into account in establishing baselines: For each technology: 2. The extent and quality of support for the technology in user agents. 3. The extent to which user agents implementing the technology conform to relevant accessibility guidelines and specifications, including the User Agent Accessibility Guidelines 1.0 as well as any applicable accessibility API's or other conventions specific to the operating system. 4. The extent to which user agents implementing the technology support a variety of user interfaces adapted to the needs of people with disabilities. (i.e., assistive technologies and alternatives interfaces). 5. The extent to which authoring tools supporting the technology implement the Authoring Tool Accessibility Guidelines, and the capacity of the developers who will write the content to implement aspects of WCAG 2.0 not sufficiently supported by the available authoring tools. 6. The extent to which the technology is backward-compatible with earlier versions for which better support is available, and the extent to which content that uses the technology can be presented and operated by software that doesn't support this technology. (i.e., does it "degrade gracefully"?) The availability, in practice, of user agents supporting both the technology and accessibility to people with disabilities who may try to access the content to which the baseline applies.
Attachments
- text/html attachment: intro_with_edits.html
Received on Wednesday, 8 March 2006 13:33:14 UTC