- From: Kynn Bartlett <kynn@idyllmtn.com>
- Date: Tue, 19 Sep 2000 10:25:18 -0700
- To: w3c-wai-gl@w3.org
Hi, everyone, if you've read message I posted on the Interest Group list, then you know where to find a list of the books I've read lately. I want to call the working group's attention to a specific book which I read last week. The book is GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers, by Jeff Johnson. In addition to having great content that many of us could learn from (although it's likely old hat to pros like Gregg), it also has an appendix which was very informative: "How This Book Was Usability Tested." (pages 535-538) I believe this is applicable because I feel that this working group (more than nearly any others in the W3C) _must_ be concerned with audience and usability by those core audiences. The bar to entry in web design is INCREDIBLY low, lower by far than that of SVG artistry or XSLT programming, and we need to make sure that our intended audiences will be able to comprehend what we're trying to say. Please note one very important point: _the W3C process does not include the level of user testing necessary for the success of this project_. The W3C process is very good at what it does -- make technical specs for product engineers -- but it is not _sufficient_ for the task which this working group has taken upon itself. As I maintain that WCAG is fundamentally different from most other W3C specifications, I suggest that we will find that we need to extend (not replace) the process to meet this group's needs. In short: I think we need to semi-formally test our work on web designers, at numerous points in the development of WCAG 2.0. Implications: * Feedback received is not sufficient. We can't assume that the average web designer knows enough about how the process works to understand that her input may actually _change_ a W3C specification; nearly all users view problems with comprehension as _their problem_ not the spec's. This means that any voluntary feedback we've received is going to be very skewed and not reliable. * A review of the "completed work" is not sufficient. We need to be able to get user responses very early in the process and throughout the life of the work. For example, there have been questions on terminology. We all have our own definitions, but that's not sufficient (especially as the average _programmer_ is used to "redefining common words" for specs, but the average _web designer_ rarely is). We should be making lists of terms and emailing them to representative users and asking them what they mean to _them_. My opinion on terms (and Charles's, and Gregg's, and Marshall's, etc.) is WORTHLESS; what matters is the reader's opinion. * Ignoring results is not sufficient. We all have various agendas to push here, but compromise will be necessary. If I propose a completely workable, elegant solution to our needs, and our audience just sits there scratching their heads, then we've failed. We need to listen to what's being said _and be ready to give up our favorite cool part of WCAG 2.0_ if it doesn't work. This isn't easy. However, if you like, I am willing to take point on actually setting up this type of user testing; I think Marshall Jansen (as the HWG representative) could also be of great help on this with the Guild's access to a HUGE number of web designers. I think this is very important. Respectfully submitted, --Kynn Bartlett WCAG Working Group Member Edapta, Inc. PS: To stave off a possible criticism: Yes, I realize that some of you may feel that web designers are _not_ the intended audience and that a more technical reader can be assumed. I feel that such viewpoints are naive and misguided, because: (a) It's simply _wrong_. In practice, huge numbers of web designers have read the WCAG 1.0 document since it was released. These are not software engineers; these are not XML experts. These are people who are designing 90% of the web sites out there, and they need the information that WCAG provides. WCAG _is_ being read by non-technical web designers. They _are_ our audience (or part of it). (b) The assumption is that a document written for a technical audience cannot be written in a way that non-technical audience can understand it. I think this shows lack of familiarity with good writing practices more than anything else; I feel that it should be perfectly possible for WCAG 2.0 to have solid technical information while not requiring a Computer Science graduate degree to understand. -- Kynn Bartlett <kynn@idyllmtn.com> http://kynn.com/ Director of Accessibility, Edapta http://www.edapta.com/ Chief Technologist, Idyll Mountain Internet http://www.idyllmtn.com/ AWARE Center Director http://www.awarecenter.org/ Accessibility Roundtable Web Broadcast http://kynn.com/+on24 What's on my bookshelf? http://kynn.com/books/
Received on Tuesday, 19 September 2000 13:38:19 UTC