- From: Nouiouat, Athmane <athmane.nouiouat@sap.com>
- Date: Mon, 9 Apr 2001 20:16:40 +0200
- To: "'Frank Gaine'" <fgaine@frontend.ie>
- Cc: "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>
Hi Frank, Without getting in the technology details, I was trying to make a philosophical point about: 1- the Design of Sites should be based on all possible types of users out there thus the concept of User Classes, from the most liberal to the most conservative styles (isn't that democracy!). I believe we will be more successfull by giving choices as opposed to mandating options. 2- Who are we to mandate to 6 Billion people how to design or what to put in their Web sites? Why not provide all, technically possible, options through the technology and let people (the users, designers, etc) choose. I could probably write a book about this! Take care athmane -----Original Message----- From: Frank Gaine [mailto:fgaine@frontend.ie] Sent: Monday, April 09, 2001 10:13 AM To: Nouiouat, Athmane; 'Kynn Bartlett'; 'jim@jimthatcher.com'; Graham Oliver; Charles McCathieNevile; Davey Leslie Cc: Kelly Ford; w3c-wai-ig@w3.org Subject: RE: Skipping navigation tactics Isn't accessibility about equality of access and choice ? Forgive me if I have misunderstood but if style sheets are used so that navigation links are not seen or heard then this defeats this objective of being able to choose. Remember, 'skip navigation' links are a priority three checkpoint and is more of a convenience issue rather than a barrier to access. Using style sheets in this way could plausibly deny access to navigational information if it is the case that they're not shown elsewhere on a page. Am I wrong ? If so, could someone please tell me how style sheets can be used effectively here ? Regards Frank -----Original Message----- From: Nouiouat, Athmane [SMTP:athmane.nouiouat@sap.com] Sent: 09 April 2001 10:04 To: 'Kynn Bartlett'; 'jim@jimthatcher.com'; Graham Oliver; Charles McCathieNevile; Davey Leslie Cc: Kelly Ford; w3c-wai-ig@w3.org Subject: RE: Skipping navigation tactics Kynn, That's exactly what I meant without developing fully: "Make the accessibility user centric", have each user configure what they want and let the tools (readers, browser, speech engines, etc) do the rest. Conceiveably, since disk space is cheap, 1 can point to CSSs and pages based on many classes of users from an accessibility perspective. At first access the user would choose and config what Accessibility class they want to use. >From then on the tools take over. athmane -----Original Message----- From: Kynn Bartlett [mailto:kynn@reef.com] Sent: Sunday, April 08, 2001 2:30 AM To: Nouiouat, Athmane; 'jim@jimthatcher.com'; Graham Oliver; Charles McCathieNevile; Davey Leslie Cc: Kelly Ford; w3c-wai-ig@w3.org Subject: RE: Skipping navigation tactics 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 Monday, 9 April 2001 14:17:10 UTC