Re: attributes, software architecture, CC/PP and accessibility

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:

  Hi,
  
  In a previous posting, Wendy asked me to look at CC/PP amd see
  if it is in sync with my ideas.
  
  Before going into that discussion, I thought it might be helpful to
  talk a little about attributes/preferences and software architecture.
  
  An arrangement that I've found helpful in software architecture is to
  provide for external attributes/preferences and internal attributes/preferences.
  The external attributes/preferences are known outside of the program
  while internal attributes/preferences are known only inside of the program.
  There are several advantages to this arrangement.  One is that the names
  used for the external attributes/preferences can be renamed, aliased, etc
  and the internal attributes/preferences can be left the same.  Only
  the mapping of the external attributes/preferences to internal
  attributes/preferences need be changes.  This arrangement also allows
  for external attributes/preferences to be specified from different sources
  using names relevant to the source without needing to change the
  internal attributes/preferences.
  
  In this arrangement, values from CC/PP would be seen as external
  attributes/preferences from the CC/PP source.  Also, a web page
  could be provided for specifying user preferences using attributes/preferences
  which need not have the same names as CC/PP.  The names would
  be more relevant to the purpose of the web page where the names
  from CC/PP would be more generic.
  
  
  Assuming that a web site provides an ability to store a user's
  preferences from a previous visit, a user preference page and the
  handling for CC/PP, the following steps would probably occur
  when a user visits the web site:
  
      1.  set internal attributes/preferences from defaults
  
      2.  set internal attributes/preferences from stored user preferences
  
      3.  query user agent for CC/PP information
  
      4.a.  if no CC/PP information is returned, display a greeting web page
  	  with a link to user preferences web page which has a list
  	  of external attributes/preferences relevant to the web site
  
      4.b.  if CC/PP information is returned, set the internal attributes/preferences
  	  from the external attributes/preferences provided by the
  	  CC/PP.  then display a greeting web page with a link
  	  to user preferences web page which has a list of external
  	  attributes/preferences relevant to the web site.  (This web
  	  page will let a user over-ride values provided by CC/PP
  	  as might be needed for the particular session.  It is also
  	  highly useful for debugging.)
  
  
  In this organization, CC/PP should identify major classes of disability,
  e.g. "blind", "upper arm limitations".  The application would then translate
  these external attributes/preferences into possible internal
  attributes/preferences like "use simple format" or "include fast
  section navigation".  (Ideally, the user preference web page would allow
  the user to turn off all features relevant to a disability or
  let the user pick and choose which disability features to include.)
  
  
  As near as I can tell, CC/PP isn't providing information about
  a person's disability.
  
  
  Scott
  

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia

Received on Tuesday, 1 February 2000 18:13:09 UTC