- From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
- Date: Wed, 28 Mar 2001 20:06:11 -0800
- To: "Paul Bohman" <paulb@cpd2.usu.edu>, <w3c-wai-ig@w3.org>
At 2:22 PM -0700 3/27/01, Paul Bohman wrote: >One of the concerns that Web developers often have is that they think that >accessible web pages are boring or ugly. That's true -- it's a startlingly persistent myth. >To disprove this myth, I am doing >"accessibility makeovers" of some of the more popular sites on the Web. I >decided to start with Barnes and Noble's Web site, because it was very >inaccessible to screen readers, and the fixes were relatively easy. Thing is, though, you can only get so far. I don't want to sound like I'm purely making a pitch for my company's product, so I'll point out that other people BESIDES Reef are exploring this concept. That said, here is my philosophy on accessibility. Yes, you can take a highly graphical, mostly inaccessible (to certain key audiences) web page and make it "accessible". This is relatively easy and won't hurt the graphical layout; in fact, this is the basis of 1999's "Kynn Challenge" -- I have yet to find any page where the graphical user interface is _harmed_ by adding elements and attributes to increase the accessibility of the page. HOWEVER, the next problem is one of usability. Once you have allowed a screenreader user to _access_ the information, the next question becomes "can they do it _well_?" And sadly, this is not the case; it is not nearly as easily done. In other words, yeah, you can get at the alt text, you can find the content on the page, but have you created a great "web user interface" for the screenreader use? The answer is a solid "no" -- it's nearly impossible to craft a web UI with a high degree of "usability" for screenreaders, while keeping that web UI a derivative of the graphical web UI. Conversely, if you want to make a web UI (by which I mean "the parts of the user interface -- presenting information, navigation, etc -- which are under the control of the web developer/designer"; in other words, the stuff you create in HTML or the like) which works _well_ in screenreaders (high degree of usability), you will probably create something which is _not_ optimized for the graphical browser user. Accessible, yes -- you can make something which can be _accessed_ by everyone -- but usable equally easily? Or putting aside even the concept of "equal" (which is darn hard to pin down), can you even make a _good_ user interface for screenreaders, based on the graphical browser user's interface? No. No, you can't. That's why I've been working on this Edapta stuff for over a year -- now "Reef EveryWare" -- because I want to see dynamically generated pages which build an accessible and _usable_ user interface for each user. Wherein each user is considered first and foremost as who they are, and not made to rely upon using "someone else's" interface with additional tags/attributes added. Whereby we deliver to each person the best we can create _for them_. Our Edapta/Reef plan is to not _only_ provide accessibility, but also to provide _usability_. The accessibility stuff is relatively easy (for most audiences) -- it's a solved problem, at least, for screenreader users -- but usability is the next hurdle. It's not enough to say "well, you can get at the alt text, use the site!"; we need to go further and treat everyone with dignity, respect, and high usability in a user-centric model. No more coding to the "least common denominator" -- code instead to each individual user. This can help with a number of other problems which are as yet fully unsolved -- such as cognitive disabilities (dynamically linking glossaries, adding icons, doing English-to-English downstep translations, etc). So that's my soapbox. I'll get off it now and say that nothing here is meant to minimize your project, which is very good and very useful. I don't want to discourage you from this course of action; indeed, I hope you proceed. However, I think it's important to note that for most of those sites you've mentioned -- which are dynamically generated database-backed sites anyway (and thus perfect platforms for dynamic adaption) -- the long-term solution will be something like the scenario I've described above, and not merely a matter of making sure the graphical browser user's version has proper "accessibility markup." --Kynn -- Kynn Bartlett <kynn@idyllmtn.com> http://www.kynn.com/
Received on Wednesday, 28 March 2001 23:21:46 UTC