a 4 Type Document Collection with Resource Site

	Daniel Wrote:

1- footnote/subsections in the overall "pure" document
  2- as a separate document still edited by the WAI group
  3- as a separate document edited by some other groups

I think we're heading toward 1 after the August meeting, but I'd like
to propose that we do 2 instead (Gregg, how about that for a moving
target...).

======================================

Hi folks,

My thoughts are as follows:

THOUGHT 1)  We need to separate out guidelines into four types
	1  Essential Stable  -
	2  Helpful Stable
	3  Essential Temporary
	4  Helpful Temporary  

ESSENTIAL - means that if you don't do it then a person can't use the page (or many people won't).
		Examples are -  alt text, text link alternatives to imagemaps, etc.
HELPFUL - means that it makes the page easier to use.
		Examples are - links with context included in them, numbered lists, etc.
STABLE - means that this is something you should do today and for the forseeable future.  
		Examples are - alt text, text version of audio presentations (speeches)
TEMPORARY - means that this is something that needs to be done to make things accessible until such time as browsers, screen readers, and servers do what is recommended by WAI guidelines for accessibility,
		Examples are - providing a D Link until enough browsers support a mechanism for displaying LONGDESC.  Special recommendations for formatting tables until browsers and or screen readers can render them properly or intelligibly.


THOUGHT 2)  We need to be able to provide as short a listing as we can focusing on the most important things.    A comprehensive listing will be too long and lose too many people.

THOUGHT 3)  We need to have a comprehensive listing that puts all the related issues together.  Some people will want this.   And it is the only way we will see errors and opportunities.  It is also the only way we can get new people up to speed so that they can contribute new ideas and be as close to on the mark as possible.

THOUGHT 4) We need to Focus on and push people toward the future and where they should be. (this includes web authors,  browser designers, screen readers, talking browsers etc.)

THOUGHT 5) We need to also remember that web sites need to be accessible today, and people want to know how to make them accessible today - with the browsers, screen readers etc as they are today (and for at least a few tomorrows) 


Now,  as to the question of what should go into guidelines.....

Partly we will need to see how the guidelines come together to make this decision. 

But at this point I think we should focus on creating the following SET of downloadable, printable documents.  (These would be supplemented by a resource web site as described below).  They SET of documents would be of the following types


TYPE A -  "2 page" overview of the importance and major issues around accessibility.
	Working title :  Web Accessibility Overview - Issues and Strategies.

TYPE B -  More in depth discussion of the access issues of people with different disabilities or access problems.   This would include an introduction to the different types of disabilities as well as the major problems faced by people with those disabilities in accessing the web today and tomorrow.
	Working Title:   Understanding Web Access Issues 

TYPE C -  QuickLists  that summarize the important issues or guidelines for different developer populations.   These would be as short as possible, and would have links to more in depth discussions should the reader not understand the brief form.  These could be used as checklists or as priority reminders.  (It will be difficult to decide what does or does not go into these.  Brevity will do battle with a desire to get as much info into these as possible due to their utility. )
	Working Titles:
		1)  A Web Authors QuickList for Disability Access
		2)  A Quicklist for More Accessible Web Browser Designs
		3)  A Quicklist for More Web Savvy Screen Readers
		4)  A Quicklist of recommendations for More Access supportive Web Servers

TYPE D -  A single (?) document that discusses the access issues and then makes recommendations for ways to address them.   
  -  Since very few problems can be addressed by only one of the web components (page, server, browser - and assistive technology if one is used) recommendations or guidelines for all of the components should be included.  
  -  Since we need to make people aware of ESSENTIAL and HELPFUL as well as STABLE or TEMPORARY techniques, I think they all need to be in this document.  They need to be clearly labeled though.  -  and I think they need to be together but separated (see below).  This however may change when we see how it flows
  -   One thing we can do to simplify the current UNIFIED guidelines (the 7.0 series) is to remove the different options and just put in the recommended.   Because the UNIFIED guidelines were from many people and groups, there are a number of places where alternate strategies are presented.  I would suggest that only the WAI recommended way  (the WAI way?) be included in the Type D document and that the rest of the ideas live in the resource site (see below).

A possible format for the Type D document would be to break it down into issues or topic areas (much as the current Unified Guidelines are.    Within each topic the breakdown might look like
	- Topic name or Access Issue
	- Access issue is described
	- Long Term WAI recommended solution is described
		a) Overall strategy for solution is presented 
		b) Page Author recommendations presented
		c) Browser Recommendations are presented
		d) Server Recommendations are presented
		e) Screen Reader Recommendations are presented
	- Short Term, Temporary Fixes are presented
		a) Things a page author can do for now if any
		b) Things a browser designer can do for now if any
		c) Things a server designer can do for now if any
		d) Things a screen reader can do for now if any

In each case the items described would be placed under a heading like
	ESSENTIAL FOR ACCESS
	IMPROVES USABILITY
They could also be given a score (1-3) but I think that may be too much.  I would avoid it unless there seems to be a very good reason for doing it.   If there is in a particular case or three the I would just put a note on those cases and leave the rest of the document simpler.

For each topic there could also be a "BELOW THE LINE" area where notes and working items are written.  This may only be a temporary feature of the working document or it may be a permanent feature.  


WEB RESOURCE SITE

In addition to the documents I would think we should maintain (or someone should) a web resource site that contains all the good information we would like to include in the documents but it won't fit.   
This could be organized in the same fashion at the TYPE D document and act as an extension of it.
This web site could include:
	-  all alternate ideas
	-  new ideas that have not been approved and or included 
	    yet in the master docs
	-  discussions on particular ideas
	-  case studies showing how to do it - or how to address 
	   exceptions or particularly difficult problems
	-  simulations (to show people what it is like)
	-  evaluation tools
	-  etc


As much as possible though, I think that we should have people looking in one place for information and not having parallel documents they should read.  Its too hard to correlate the different sections in the different docs.  Also I doubt if WE could keep them all in synch.    We do need  short forms for the different groups though and the QuickLists is intended to meet that need.   This is my best guess as to how to keep it as simple as possible while providing the different types of info.    There of  course is no good answer.  The attempt here is to achieve a balance or best fit of the different needs.

    Let  me know what you think.



Gregg  (Van)

Received on Wednesday, 20 August 1997 09:04:24 UTC