- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 28 Jan 2002 10:16:36 -0500 (EST)
- To: Gregg Vanderheiden <GV@TRACE.WISC.EDU>
- cc: "GLWAI Guidelines WG (GL - WAI Guidelines WG)" <w3c-wai-gl@w3.org>
I have commented on some proposals below - others are fine I think. Change "WCAG 2.0 will clearly identify the target audience of each requirement." to: WCAG 2.0 will clearly identify who will benefit from each requirement" CMN Proposed: ...will clearly identify at least some groups who... rationale: We are not, in my experience, great at developung exhaustive lists, but it is helpful to at least demonstrate that something is required. For example, as I understand it the need to avoid flashing content was understood long before finishing WCAG 1 as a requirement for people with photo-sensitive epilepsy (and to apply particularly in a certain frequency range). Long afterwards, it became clear that this requirement was also applicable to people with certain disabilies related to attention span and the ability to concentrate in the presence of distractions. About the same time I learned that it was also crucial for users of a (then widespread, and now mostly used in South America) screenreader that simply stopped - a typical "until user agents" type case, although not aplicable to english language. -------------------------------------- Combine A-1, A-2, and A-3 into one item that reads: A -1 The working group acknowledges that accessibility to everyone is not possible. Our target is to make things as accessible to as many people as possible given then need to have practical techniques and criteria. We will expend our best effort to identify techniques, criteria and examples that would cover the greatest range possible. CMN Proposed: The working group acknowledges that accessibility for everyone may not always be possible. Our target is to make things as accessible to as many people as possible, but there is a requirement that we need to specify in terms of verifiable requirements. We will expend our best effort to identify techniques and examples that cover the greatest range of people we can. Rationale: 1. In some cases it may not be impossible either. 2. "practical" means different things to different people, and relates heavily to circumstances people are in. I think what we mean by it is that we have constraints imposed by our requirements, that affect what we can propose as a requirement. These constraints do not, however, affect what we can propose as a technique, as I understand things. -------------------------------------- --------------------------------- Tune up S1 so that it is clearer what is meant. It would now read: S1 - Serving content in different forms in order to meet different user needs or preferences is an acceptable way to comply with the guidelines, -- as long as equivalents for all of the information are provided in the different forms, and it is all available from the same URI. (Accessible, findable links to alternate form(s) is allowed.) (Server side solutions are acceptable - as specified.) CMN This still seems unclear to me as a way of phrasing what we mean. Does it mean every version must be content-negotiated, to keep the URI the same (in parctice this doesn't work with existing systems, where a specific version can come from a generic, content-negotiated URI, or can come from a specific version URI), or does it mean that it must be possible (easy?) to get from one version to another by some means? I therefore propose that we mark this as an issue still open until we can produce (or the editors can propose) some wording that seems less fuzzy Charles McCN
Received on Monday, 28 January 2002 10:16:37 UTC