- From: Scott Luebking <phoenixl@netcom.com>
- Date: Tue, 1 Feb 2000 20:46:17 -0800 (PST)
- To: charles@w3.org, phoenixl@netcom.com
- Cc: w3c-wai-gl@w3.org
Hi, Charles The problem with using something rather specific like "fast navigation" is that it limits the choices regarding accessibility that a web site can make in response to CC/PP information. For example, suppose that a web page is presenting information which can be more easily analyzed by blind users if the web page provides certain features. The CC/PP would not know about the existence of these features. However, if the CC/PP specifies that the user is blind, the web server could map the external attribute/preference of "blind" into a set of internal attribute/preference features appropriate for many blind users. (The blind user can fine tune the choices by the web site's user preference web page.) The question of how CC/PP attributes of "blind", "upper arm limitation", etc, will be received is a hard one. For example, some blind people will have no problem with that. Like one blind person said, how many people walk around with white canes or read with their finger tips? Other blind people will be concerned about something being labeled "blind". Whatever decision is made, someone will disagree with it. Scott > This seems like a pretty sound approach in general. However I am not sure > that having preference settings like "upper arm disability" is going to be as > well received as having the resulting features be what the user selects on - > fast navigation, no images, or whatever. > > Charles Munat has also worked on this approach a fair bit, but doing browser > sniffing to determine whether to include thins like accesskeys (based on the > idea that if the browser doesn't handle them they are a wase of > bandwidth). As I understand it, CC/PP does not deal specifically with > disabilities, but instead with functional requirements/limitations. Another > area this is being used is with system atributes in SMIL and SVG. > > Cheers > > Charles McCN > > On Tue, 1 Feb 2000, Scott Luebking wrote:
Received on Tuesday, 1 February 2000 23:48:52 UTC