Re: a 4 Type Document Collection with Resource Site

to follow up on what Josh Krieger said:

> I just got around to reading Greg's 4-type document note.
> In particular, in document type D, he gives the following 
> suggestion for reorganization:
> 
> Gregg Vanderheiden wrote:
> > 
> > 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
> 
> I think this is right on, though I would argue that the current
> guidelines are not really in this format. If we could formalize the
> WAI guidelines into this format it's precisely what we need.
> We should be very careful about stressing the access 
> issues without getting lost in idiosyncracies of only one 
> of the 3-tuple of access agent, browser, document encoding.
> 

Yet another concept:

Particularly in the long-range timeframe, the recommended practices
solve multiple problems.  So rather than one hierarchy where
solutions are presented listed _under_ problems, what we might want to
do is have two cross-linked trees:

	Problems
		induced by disabilities affecting display
			sight
			sound
			language (dyslexia, illiteracy, ...)
			...
		induced by disabilities affecting control
			large motor
			small motor
			...
	Practices
		HTML markup
			now
				summary
				links to database layer for live examples
			under development
				summary
				links to development activity
		Site management
			...
		Authoring tools and methods
			...
		[adaptive pipe]
			...
		Browser
			...
		Access agent [between browser and user]
			...


If this is the outer sorting structure, then for each access issue
or Present Point of Pain we can have 

	Definition of the problem
		summary
		.. includes links to first-person accounts
	Analysis of the problem
		brief
		.. includes links to research results
	Solution strategies
		now
			.. includes links to "practices" paragraphs
		under development
			.. includes links to development activities

Each solution strategy is in general a pattern of practices.  The
description of a solution strategy should be brief and include
links to the Practices writeups.

And the Practices writeups will have links to the Problems that
they affect.  Some of these may be negative influences.  We can't
limit ourselves to discussing practices that are universally good
for everyone in today's technology context because there aren't
enough of those practices.

Some of the things that HTML authors can do are good "regardless
of what the other system segments do" and that is good
risk-avoidance.  But even in the short term, there are also
strategies which require cooperative practices at different
layers in the system.  We probably need to consider some of
these, too.

There should be some mamagement goals regarding total byte count
in this writeup.  There should be overall more bytes devoted to
things people can do now than what is expended on "we're working
on a real solution."

I don't think that it makes sense to avoid naming names of
individual browsers in the descriptions of the present points of
pain.  We may be able to cover this in the database layer a bit,
but I don't think that at the present time we can afford a "no
browser names" rule in this writeup.

--
Al Gilman

Received on Sunday, 24 August 1997 11:28:14 UTC