- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Tue, 12 Aug 2003 11:05:16 -0500
- To: cb@ftb-volmarstein.de, w3c-wai-gl@w3.org
Hi Christian. Thanks for the comments. Don't worry about frankness. It is what we need. Couple of points for your consideration and feedback. Core items include only those things that 1- are measurable - reliably (machine or human with high inter-rater reliability) 2- do not restrict what you say or how you say it. The reason for #1 - is that we can't have required success criteria that you cannot tell if you have passed. This is required for both core and extended success criteria. The reason for #2 - we cannot require that people write in a particular way. Otherwise we would restrict expression - rather than asking that expression be accessible. Regarding people with cognitive disabilities: We are worried that text will be written so that it is not understandable by people with cognitive disabilities, but then again that will always be true. No matter how simple we make it - there will be people who cannot understand it - or understand written or even iconic presentations of the information. For example, this email will only be comprehensible by some people no matter how simply I write it. But as I write it more and more simply, I will also start losing information that can be conveyed if I don't have to write it to be understood by someone with all levels of cognitive disability. And expressing it in pictures or icons won't reach them either. So where does one stop. And when I stop - I will have not met the needs of those below that level -- and will have deleted information that was comprehensible to those above that level. So the solution SEEMS to be. 1 - write as simply as you feel appropriate to express the information the way you want to. Then either (or both) a) mark up the text so that it can be unambiguously interpreted by translators. b) provide additional versions at other language/cognitive levels. The attempt here has been to make the text unambiguous if possible... then rely on future technologies to "translate it" into a simpler form (at whatever level) to match the level of the user. Then as an extended checkpoint -- suggest wording things simpler or having additional version or versions in simpler language level or levels. SUMMARY Thus important things that are not objectively measurable, and things like creating another version that is simpler - are extended checkpoints. Any government may decide to require an extended guideline. But in general - they are not required for a reason like above - and we will be commenting on why they are not CORE and shouldn't in general be required. This isn't the whole story but it gives you an idea of what we have been thinking. Please join the group if you can. We would love your input in the discussions. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: public-comments-wcag20-request@w3.org [mailto:public-comments-wcag20-request@w3.org] On Behalf Of Christian Buehler Sent: Monday, August 04, 2003 6:08 AM To: public-comments-wcag20@w3.org Cc: Judy Brewer Subject: Re: Call for Review: Working Draft of Web Content Accessibility Guidelines 2.0 Dear WAI WCAG members, thank you for the work and enthusiasm you put into WCAG 2.0. After following the development of WCAG 2.0 for some time, we want to comment on the current version (June 24 2003). Our comments are based on the experience with WCAG 1.0 and the German decree BITV, which basically requires German federal public websites to conform with AA. The experience includes advice for designers, testing of web-sites, feedback and discussion with disability groups, feed back and discussion with web designers and federal agencies. 1. The most important request is that a smooth transition form WCAG 1.0 to WCAG 2.0 is possible and supported by WAI. This is absolutely mandatory, if one does not want to jeopardise the efforts that Governments adopt W3C-WAI guidelines, as currently recommended in the European Union. The current version represents a major change, which is likely to create big problems in this respect. 2. The advice promised for the transition of 1.0 to 2.0, needs to be available, before the WCAG 2.0 can become an official recommendation. The current checkpoint mapping is not at all sufficient (contarily, it highlights very clearly the problems of the transition). The advice should follow a scheme. I conform with A or AA, or AAA which are the new additional requirements? Which are the obsolete 1.0 guidelines and checkpoints? 3. In WCAG it is said that priority 1 removes barriers, which can't be overcome, priority 2 removes significant barriers, etc. What is the case for the types core and extended? Does core remove all significant barriers? Any statement planned like in 1.0? 4. Why moving from priorities to types. What is the difference? I would stick with the concept of priorities. That would be more consistent with WCAG 1.0. 5. Agree to have only two levels. Please avoid the core + thing. This makes it very complicated. It is much easier to deal with 2 clear levels. If you stay with things like core + etc, you open up the creation of new standards like "Core+ Germany" (which is defined somehow). If you want more variety, please go ahead. 6. A very big concern is that WCAG 2.0 in the current format, does not adequately consider the needs of older people, people with less computer skills, people who have problems to understand complex language. You put most of the very important requirements in this respect under extended. This is not acceptable. We have big debates here on how to support the needs of these people, like those who have sign language as first language (the need a simple grammar, short sentences, etc.) or the ones with slight mental problems, who ask for less terminology, better layouts, clear navigation etc. If WCAG 2.0 does not consider this appropriately, it will miss the opportunity to turn from a "blindness" oriented scheme to a (dis)ability oriented one. 7. Your checkpoint 1.6 is extended: Why? Many people with visual impairment benefit form good colour contrast. And the ordinary user, will not be able to do all settings her- or himself to get a good colour contrast. So this should be core. 8. Similar 2.4 needs to get on core level (see 6.) Maybe the success criteria need to be changed then. 9. Similar 3.3 and 3.4 are clearly core requirements (see 6). (What about the need of content, one can perceive but never understand!) 10 If you kill 4.3, what happens to accessible scripts or alternatives to scripts then? No recommendations on this at all? Generally: The WCAG 1.0 was at the time rather strict and provided many very clear recommendations, for example old 2.1 (information conveyed with colour should be available without colour). Now this is included in 1.3 separation of info/ structure/ presentation. Well, it is basically there, but it needs to be supported by success criteria, which is not in the current version.(It is not sufficient to put it down to technical docs. It needs to be part of WCAG 2.0) Every WCAG 1.0 guideline and checkpoint need to be visited to make sure that if it is still valid, it has found appropriate entrance to WCAG 2.0. If I go to the Mapping list, I really wonder why so many important WCAG Priority 2 issues have put to the type extended. Also the level of aggregation of criteria in one single headline seems not very helpful in the end. (In the beginning it reads much easier, but one needs to go to the details for the practical case.) When I read the draft WCAG 2.0 a year ago, I thought it was on a good way. Today, I have much more reservations. In a country, which uses WCAG 1.0 as a baseline for its legislation, I forsee big problems, if this WCAG 2.0 will replace 1.0. I recommend to take the time to produce a WCAG 2.0, which considers appropriately all disability groups and allows a smooth transition from 1.0 to the new one. If that is not done properly, WCAG 2.0 will be not meet the target. Maybe weI misunderstood some concepts. If so we would be glad to learn. Otherwise, our criticism was formulated very frankly, in order to be as clear as possible and to support the process as much as possible. Best regards Christian Buehler
Received on Tuesday, 12 August 2003 12:05:32 UTC