Re: Table linearization (was: A table navigation technique)

to follow up on what Jon Gunderson said:

> We have also been lacking any significant discussion of how
> this may be implemented in browser other than it can be done
> through third party assistive technology manipulating the DOM.

There are concepts for how this could be integrated into the CSS
implementation in a browser that were identified in the earlier
review of CSS2.  This is basically to allow CSS selectors to
follow logical relationships in the document model, and to let
the user control document flow as well as finish.

Examples of following logical relationships:

	what column am I in? column group(s)? row group(s)?
	what header am I immediatly {under, over, after, before}
	what headers am I ultimately {"}
	what is the label for this control?

These are things that are deterministic given a well-formed
document, but not accessible via CSS selectors at this time.
I haven't checked on the DOM implementation of closing these loops.

So, one way to implement linearization in the W3C web technology
would be to 

	1) define a core aural flow model, parallel to the
	present visual flow model as presented in the CSS2 Recommendation

	2) provide a default binding of HTML4.0 structures
	to this aural flow model

	3) allow personality sheets (whether called style sheets
	or behavior sheets) to override the defaults and user
	sheets to override the author sheets as was corrected in CSS2.

	4) the UI gives the user a high-level choice of flow 
	model plus on-the-fly control of the same
	presentation content/flow/property rules as the personality
	sheets do; as with document templates there is a separate
	question on exit whether to save the current presentation
	mode as default in the user's personality sheet.

I agree with Paul that for many uses the ability to select an
arbitrary (non-contiguous) sub-table of the table is desirable.
This is accomplished via the above strategy by selecting the
visual flow model and adjusting display:[show | hide | minimize]
setings on the fly in the presentation-directive state of the
browse session or table object.

Note that the absense of a <css:display="minimize"> option in the
CSS display property is a bug so far as adapting robustly to
different users' needs is concerned.  In a spreadsheet or table
filtered display it would often be useful to a) have an
indication where rows or columns have been suppressed and b) have
a convenient way to add suppressed rows or columns back into the
display.

All of this can be experienced by using print formatting in a
spreadsheet or view construction in a WYSIWYG data access tool.

> Jon
> 
> 
> At 04:02 PM 11/17/98 -0600, Paul Adelson wrote:
> >Following up Jon Gunderson's comment:
> >
> >> <snip>
> >
> >> In a study we did here at UIUC with low vision students.  We found the most
> >> difficult task we asked them to perform was to find some information in a
> >> simple data table (3 out of 4 visually impaired students could not complete
> >> the task).
> >>
> >> So how do we address the needs of these disabilities related to table
> >> linearization?
> >
> >A question from a naive bystander: is table linearization the best way to
> help
> >low-vision users, or are there other good options?
> >
> >I ask partly because I sometimes deal with scrolled-off (and therefore
> >invisible) column headers on spreadsheets by getting the cursor onto a column
> >of interest and then cursoring down to find the row I'm interested in. This
> >allows me to quickly look at the data in the column I'm interested in,
> without
> >having to deal with all the other columns. I don't think this would be as
> easy
> >to do in a linearized table.
> >
> >The other option I use (if I'm feeling less lazy) is to lock the cells that
> >contain the column and/or row headers so that they are always in view. The
> >equivalent for general browsing would be to have the option of readily
> >viewing/hearing/feeling the related headers for any cell that is currently
> >being rendered. This might be done with or without linearization.
> >
> >So, here's the important piece of info that I don't know: Would low-vision,
> >learning-disabled, or even blind users be readily able to navigate a 2-D
> table
> >if they always had easy access to the current column/row header info, in
> which
> >case the guidelines might do well to allow developers flexibility in how they
> >implement a solution? Or is linearization a) known to work reliably and b)
> the
> >only option that is known to work reliably, in which case the guidelines
> might
> >do better to specify this more precise solution?
> >
> >--
> >  -- Paul Adelson
> >------
> >* The views expressed are those of the
> >* author and do not necessarily reflect the
> >* position of Citibank or its affiliates.
> > 
> Jon Gunderson, Ph.D., ATP
> Coordinator of Assistive Communication and Information Technology
> Division of Rehabilitation - Education Services
> University of Illinois at Urbana/Champaign
> 1207 S. Oak Street
> Champaign, IL 61820
> 
> Voice: 217-244-5870
> Fax: 217-333-0248
> E-mail: jongund@uiuc.edu
> WWW:	http://www.staff.uiuc.edu/~jongund
> 	http://www.als.uiuc.edu/InfoTechAccess
>

Received on Wednesday, 18 November 1998 11:49:30 UTC