- From: Scott Luebking <phoenixl@netcom.com>
- Date: Mon, 15 Nov 1999 10:06:27 -0800 (PST)
- To: kasday@acm.org, phoenixl@netcom.com, w3c-wai-ig@w3.org
Hi, Len Just to give a little perspective on how I see the issues. I have to admit I don't believe in universal design in all situations. For example, I don't want a universally designed wheelchair. I want one that fits my needs. My needs might conflict with another disabled person's needs. For example, I need a wheelchair a certain height. Other people need their chairs other heights. The approach that is often taken is to design the wheelchair so it can be configured to meet a particular person's needs. Basically universal design is appropriate when it is cost prohibitive to have many variations to accomodate each person's needs. For example, having hamburgers which more closely meet each customer's preference is probably not that much more expensive than "universally-designed" hamburgers. On the other hand, highly customer-specific cars can be very expensive. I believe that the web is and will be heading towards more personalization. For example, according to this morning's San Francisco Chronicle The theme of Bill Gate's opening speech at Comdex was the "personal web". In another example, I've developed some very simple free software which lets web sites generate web pages according to user needs. I've been getting requests for the software from universities, portal developers, catalog developers, long distance learning, realty sites, etc. The idea is that the web should adapt to the user rather than the other way around. Coming from that view, I thought it would be helpful to create my example of a web page tailored to meet a blind user's needs. My example isn't complete in certain ways, but I wanted to get to the central issues. A goal I had for the web page was to let a blind user be as efficient as possible. A rough measure of efficiency was number of keystrokes ncluding any to the web page or to the access technology. One way to reduce the number of keystrokes is to reduce the dependency on location to get information or action. Using an alert box is much more efficient than an index at the bottom of the page. A good analysis of efficiency would include looking at the efficiency of getting the index information any time during the interaction with the page. For example, if the user is in the middle of the page, how many keystrokes are needed to find the index at the end of the page. Then, how many keystrokes are needed to return back to the exact position in the middle of the page. Breaking a web page into categories is much easier for a blind user to decide what to look at. A sighted person can scan over a page which a blind person can't. It is hard for a blind person to search a page based on concept rather than eaxct words. Using the categories can help with that. Try listening to both pages in the example using a screen reader and not looking at the page. See which is easier to naviage or interact with. The question you asked implies that there is perhaps a primary and a secondary form of the pages. In a system of dynamically generated pages, the idea would be the match between the page and the user. While there are aspects of accessibility which should be included in the version of the page for sighted users in order to accomodate people with other disabilities, there might not be the same need for features needed for blind users. For example, the issues of tables is a blind issue which is in conflict with visual appearance. Since it is pretty clear, that current CSS is not supported in a standard way by newer browsers or even supported by older browsers, it probably makes sense to let the pages for sighted users use tables for visual layout and effects, but limit tables in the blind versions to just data presentation when needed. In an environment where pages are being generated dynamically any way, I believe it would be easier to be able to generate multiple formats. For example, the web page formatted for a blind user is actually pretty easier to create. It's almost pure text with forms. No colors. No fonts. No images. No needing to line everything up to create a balanced, non-jagged presentation. It's really easy to crank it out. I believe adding post-processing will just complicate things. Post-processing is more apprpriate for environments where there is less control of how the pages are created originally. The javascript that is in the page now supports the event handling for both explorer and netscape. Also, the architecture for the event handling is table driven so that adding events means just adding key event entries to the table. The underlying code is kept quite independent from the initialization function. Scott > Hi Scott, > > Thank for the extra example. I just want to check one thing to preempt any > misunderstanding. Even though you offer a page with alternate layout and > other changes to make browsing more efficient with screenreaders, you still > make the default page "accessible" in the conventional sense, right? > > For example, the default page would still satisfy the web accessibility > guidelines... alt text, table reading order, etc. It's just that the > alternate page would be more efficient to use. > > As for the details... > > 1. It does seem useful to have an alternate layout where the section of > links and references come at the end instead of the beginning. It might > also be useful to have a link at the start of the page to jump to that section > > 2. You speak of leaving out decorative images, but why not accomplish that > by simply having null alt text? A ha. Reading further down, you speak of > the need to have as much text on the screen as possible. Omitting the > images accomplishes that. I assume that applies to browser/screenreader > setups which are limited to reading what's literally visible on the screen. > That problem will go away when all setups have access to all text in the > logical window regardless of what's visible... at least for people using > screenreaders. > > However, it will still help people with low vision it seems to me to not > have screen real estate used up with decoration. > > That is indeed a very interesting point. > > 3. You mention that an alternate format makes it easier to flow the text > equivalent of the image into the text. Good point. I sometimes go a bit > crazy trying to figure out ALT text for a picture so that it all reads > smoothly within the text. > > > Some of what you're talking about could be accomplished by post-processing > an existing web page (e.g. 1 and 2 but probably not 3). More food for > thought for the Evaluation and Tools Group. > > Len
Received on Monday, 15 November 1999 13:11:43 UTC