- From: Kynn Bartlett <kynn@reef.com>
- Date: Sun, 08 Apr 2001 02:30:20 -0700
- To: "Nouiouat, Athmane" <athmane.nouiouat@sap.com>, "'jim@jimthatcher.com'" <jim@jimthatcher.com>, Graham Oliver <graham_oliver@yahoo.com>, Charles McCathieNevile <charles@w3.org>, Davey Leslie <davey@inx-jp.org>
- Cc: Kelly Ford <kelly@kellford.com>, w3c-wai-ig@w3.org
Another long Kynn spiel. Skip it if you're tired of hearing me describe my philosophy on alternate site versions. :) At 11:32 PM 4/7/2001, Nouiouat, Athmane wrote: >Hi, > >What about switch for accessibility? For example the first home-page would >ask the user if they >want Full-WAI-accesibility if so send them displays with accessibility >features, if they don't >display to them withoout any worry. If the site is carefully designed, one >can assume, that stitically >(or dynamically with ASP/JSP) two versions of the site (1 for accessiblity >the other without) is achievable! >athmane Hi, good concept, but it's not quite all the way there yet. For example, the idea of having an "accessible" version and a "non-accessible" one makes no sense -- because accessibility is all about -people-. Who is a particular version of a site accessible to, and who is it not? These are the terms we think of when designing alternate versions of a web site. In your case, you would make one that is "full WAI accessibility" (note: there is no such concept in the W3C) and one which, presumably, is not. A better model is to identify for whom you are making an alternate version, and work from there. This is a user-centric view of alternative site versions! For example, many people would consider the site you describe above, that is "more accessible", to likely be one which is designed to work with a screenreader. That may -not- be the "more accessible" version for certain _other_ audiences, such as limited textual comprehension users, or limited dexterity users. So casting things in terms simply of "more accessible" and "less accessible" is not the way to go. Instead, let's consider how we can make different versions which _meet the needs of users_. We'll start with the "default" version -- what we called at Edapta the 50% user. This is the basic graphical version; most likely it is not "basic" and all and may be the most complex of the lot! Now, since we have the information (somewhere) necessary to generate "more accessible" versions, we have no real reason _not_ to include those accessibility-helpful features (elements, attributes, etc.) which can increase the number of people who can use our "default" version. In fact, since some people may not be switching right away (or may not be able to find the switching mechanism) it may be a good assumption that people with various disabilities may be using this version. So we'll make it a good one -- as WCAG compliant as possible, for example. But then we'll move on and create other versions of the site which not only provide accessibility, but provide usability for specific audiences. We'll start with screenreader users, and provide a version of our site which is made to work well with screenreaders. What are the problems facing screenreader users? Well, here's a few (this isn't a comprehensive list): 1. Simple, basic access to content -- images which are not labeled with ALT text. 2. The order of the content can be confusing and un-usable (in the "usability" sense of things) because the order is a derivative of the graphical layout. 3. It's hard to get a good sense of context; to know where you are in a page. Also, because of the linear nature of screenreader use, you generally have to experience the entire page to find out what the content is. Now, these can all be worked around to some degree -- which is why our graphical "default" layout can be made accessible. However, we can make it even easier -- without complex work-arounds -- if we simply design a new user interface for the screenreader version. Here's how I'd address those needs: 1. Well, this is actually solved. We said that our "default graphical" version has access to information such as ALT text; therefore it's not going to be hard to include that in the screenreader version. So this is pretty much a gimme. 2. We'll re-order the page to make sense; if we can set things up so that the user has the ability to enter an index of "this is the most important, here's the next, etc" for each bit of content, so much the better. If not, we'll make educated guesses based on what we know about layout. (In other words, in the typical web layout of "Something on the top, something on the left, something on the right, something in the middle, and something on the bottom", we can usually guess that the top will be identification and perhaps a banner ad; the left will be primary navigation; the right will be secondary navigation and sidebar content; and the bottom will be tertiary navigation and indicia. The middle is what we're after; that's where we can usually find the meat of the content! This is exactly how graphical web page users' visual processing of page content works, and we'll try to model it, either through guesses or through explicit author identification.) 3. Finally, we'll construct a "table of contents" for the page and make sure we have intra-page anchors and other identifying marks to give structure which wouldn't make much sense to graphical layouts (which already have this information represented simply in the graphic design). A good example: We'll put text at the end of the page which says "end of page". So what does this accomplish? We now have two interfaces -- one for graphical use which relies on traditional "graceful degradation" for diverse access, and one which is specialized for screenreader users. Neither one is "more accessible" or "less accessible", at least, not if you are using those terms alone; a version may be more accessible OR less accessible to a _specific person_ based on that person's particular ways of using the web. Only when you speak of "more accessible to WHOM" or "less accessible to WHOM" does that type of comparison make much sense. (The same applies to "usability.") This approach allows you to create, for specific audiences, interfaces which are designed to be more accessible and/or usable to _that specific audience_ without having to worry about the implications for other audiences (whose versions of the site remain "intact" and unchanged no matter what you do to the other versions). I have hopes that this type of concept will be able to crack some of the "tougher nuts" in web accessibility, such as how to solve the thorny issues related to cognitive disabilities, where the changes suggested might result in "completely unacceptable" alterations to the "default" interface if you are not doing something like this. (Under a system such as the one described, the default interface can remain unchanged and a new one simply generated for those with specific needs.) --Kynn -- Kynn Bartlett <kynn@reef.com> Technical Developer Liaison Reef North America Tel +1 949-567-7006 ________________________________________ ACCESSIBILITY IS DYNAMIC. TAKE CONTROL. ________________________________________ http://www.reef.com
Received on Sunday, 8 April 2001 05:23:47 UTC