Beta of "Human Factors Programming" BookMonday August 9th, 1999Mitch Gould writes, "'HumanFact(tm)' currently provides 'beta' excerpts from a book-in-the-making, Human Factors Programming with the Document Object Model. Your feedback is welcome. Chapter 1 Chapter 2 WebAccess CheckPage 'Beta' version August 3, 1999. Send 'bug reports' to: humanfact@generalpicture.com. You get the general picture (tm)." Thanks, Mitch! > GIVE ALL USERS ACCESS So it says, anyway. So I was most amused to discover I couldn't access the site using Lynx. :) I fail to see much (if any) advantage in insisting on Javascript support to be able to navigate a site. It certainly seems to go against the spirit of what some of the book is saying. (apologies for the anonymity: it's because I've misplaced my password, not because I'm afraid of reprisals from the author :) >Guideline 1-K >I have ensured that the document is usable when scripts and applets are not supported or >have been disabled. If this is not possible, I provide equivalent information on an >alternative accessible page. oh well, guess thats why their guidlines, not rules. Overallm I like the content, it prvide lots of example, but the problem is.... some of those example doesn't work well on Navigator 4.x.. These points are well taken. (1) Yes, the site should definitely be accessible from Lynx, and it isn't yet. Perhaps this demonstrates that these guidelines are just great in theory--but difficult to handle unless you have the staff to implement all their many demands. The smaller your operation is and the more your are trying to accomplish, the harder it is to follow these guidelines--at least in a timely fashion. Note that I had to code every byte of this site by hand because there is no editor on Earth that lets me implement all of HTML 4.0's features, at least not without some noxious interference. Your implied offer to transcode the site for full Lynx compatibility TODAY is gratefully accepted... (2) As far not being able to understand the advantage of JavaScripted links--obviously you don't and won't, as long you imagine the world is created solely for your own convenience as a user. I find the JavaScripted links are a very powerful way to assemble such a large collection of pages without managing hard-coded HREFS. Perhaps the moral of this story is that you have to be realistic about whether you can really afford to make all the sacrifices demanded by the WAI guidelines. Take this exercise too literally, I think, and you're just doomed. 3. Yes, Navigator 4 doesn't do such a great job with these pages. Maybe the moral of that story is this is why HTML 4.0 and CSS haven't been as popular as they ought to be. We are ALL facing difficult decisions about getting on with the future of the Web or just staying stuck with the kludges of the past because we'll annoy X number of legacy users if we try. I would like to add that I've reported on the concepts and recommended techniques behind the WAI guidelines, but that doesn't mean I endorse them all equally. I should have said in the chapters that I find the Initiative somewhat naive, idealistic, and sometimes even self-contradictory. Frankly, I believe it isn't essentially radical enough. A better solution is to steer authors away from publishing documents all together towards creating interactive applications designed to answer questions without forcing users to navigate through documents to find their questions answered. (Just don't expect me to show you how to do that today, though!) Having stated that disclaimer, I generally endorse the aims and practices of WAI. For the most part, I think it's good and appropriate, and remember, I believe this isn't just about a small number of disabled users... --Mitch Depending on what sort of editor you like to use for these things, you might want to try EditPlus or HomeSite. They're not WYSIWYG, but they both offer good support for HTML editing (and I believe that WYSIWYG editors are evil and misleading anyway :) There are other ways around the evils of hard-coding links into your text than using Javascript (and putting users who don't have it, or turn it off for security reasons/personal preference at a disadvantage). I'm working on a large website project at the moment that does that (by specifying the site structure separately from the content, then compiling this into a set of pages with hard-coded links). This sort of approach can easily be scaled down. To my mind it's preferable to using Javascript for the same purpose: yes, it requires a small amount of coding work up front, but then you have to write the Javascript code too. Either way, once you've written it once, you can keep on using it. |