Re: A look at tables

We have many checkpoints that relate to tables, the most prominent are:

Checkpoint 2.1 Ensure that the user has access to all content, including
alternative equivalents for content. [Priority 1] 

Checkpoint 5.1 Provide programmatic read and write access to content by
conforming to W3C Document Object Model (DOM) specifications and exporting
interfaces defined by those specifications. [Priority 1] 

Checkpoint 8.1 Convey the author-specified purpose of each table and the
relationships among the table cells and headers. [Priority 1] 

We spent alot of time of the issue of navigation of tables.  How tables are
navigated natively by a user agent is based on how the user agent renders
information.  For a graphical user agents the navigation requirements to
access content is different than a voice or Braille rendering user agent of
content, inlcuding table content.  To try to force one type of navigation
for a certain type of rendering on another type of rendering led to many
problems.  The efforts in these areas led to lthe development of
checkpoints that sounded like techniques that worked in certain situations
or plateforms, but did not provide a uniform method for navigating the
entire content of a document.  This would results in users having to gain
even more special knowlegde to know how to navigate content.  The DOM was
the bidge the group found as currently the best means to provide bridges
between different types of rendering by assistive technologies.  The DOM
allows assistive technologies to develop wholistic navigation mechanisms
based on their rendering of content.

Jon
  

At 09:56 AM 12/27/99 -0600, schwer@us.ibm.com wrote:
>
>
>
>User agents should not be considered with table navigation because it is an
>unwarranted burden on them. This should be left up to the assistive
>technology. The example mentioned below does not deal with an embedded
>table or cells spanning multiple columns. The task is very complex.
>Furthermore, your table navigation mechansim may need to change for
>different types of devices.
>
>Rich
>
>
>Rich Schwerdtfeger
>Lead Architect, IBM Special Needs Systems
>EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
>
>"Two roads diverged in a wood, and I -
>I took the one less traveled by, and that has made all the difference.",
>Frost
>
>
>Ian Jacobs <ij@w3.org> on 12/20/99 08:52:17 PM
>
>To:   Scott Luebking <phoenixl@netcom.com>
>cc:   w3c-wai-ua@w3.org
>Subject:  Re: A look at tables
>
>
>
>
>Scott Luebking wrote:
>>
>> Hi,
>>
>> Maybe a way to look at tables is to forget the presentation and think
>> of them in terms of navigation.  I believe that it will not be possible
>> to bind all the different navigation possibilities to individual
>> keystrokes (though it would be possible to do that for the more
>> frequent table navigation actions).
>
>Yes.
>> For example, there should be the
>> ability to go directly to a specific cell which would require
>> multiple keystrokes.  Similarly, the ability for full relative movement,
>> e.g. left 7 columns and down 43 rows, will need multiple keystrokes.
>
>I'll add relative "direct" navigation to the techniques.
>
>> So, any table navigation should support specifying the navigation
>> by multiple keystrokes.
>
>I'm not sure if I agree with that. I think the number of keystrokes
>is separate from the functionalities you describe.
>
>> Another question to ask is whether the table navigation can be expressed
>> in a closed symbolic form.  This is helpful in analyzing the complexity
>> of the navigation expression.  (Sorry about bringing in some computer
>> science here.)  I believe much of the table navigation can be described
>by:
>>
>>     [h|m|f] [+|-] [n|$] , [+|-] [n|$]
>>
>> where:
>>
>>     h  -  header area
>>     m  -  main area
>>     f  -  footer area
>>     n  -  a string of digits
>>     $  -  last row or column
>>
>> Direct cell navigation is expressed by not including the signs.  Relative
>> cell navigation is specified by including the signs.  Mixed navigation
>> is also supported.
>
>What is "mixed navigation"?
>
>> So any navigation system which can be shown to map into
>> this representation would be rather complete.
>
>> A table navigation problem is to what cell does the user go when moving
>> out of a span cell.  For example, if the span cell is three columns
>> wide, to which cell does the user go when they choose to go down.
>
>To the row below..
>
>> Similarly, if the user is in a cell in a row with 5 columns, but the
>> next row with 5 columns is 7 rows down, where does the user go when they
>> go down?  I think navigation could be simpler by navigating through a
>> different concept of a table.  Instead of using the HTML table as the
>> basis of navigation, a "normalized" table could be used onto which the
>> HTML table is mapped.  (I'm sorry about getting abstract here, but I
>> think it does actually simplify some of the navigation issues.)  A
>> normalized table is one where all the rows have the same number of
>> columns and all the columns have the same number of rows.  Each cell in
>> an HTML table maps into one or more cells in the normalized table.  A
>> span cell in an HTML table occupies a set of continous cells in the
>> normalized table.  For example, if a span HTML cell spans 3 columns and
>> two rows, it would map into a block of cells 3 columns wide and two rows
>> high in the normalized table.
>
>Yes, I think it would be disorienting to move from row N down one row
>and find yourself in row N + 20. Instead, you might have to have
>to have your position adjusted left or right. Cells (in the HTML model)
>start in the row / column position where they are specified. They may
>extend into the row or column (left or right depending on the table
>direction).
>In the case you describe above, I'd move the focus down one row
>into the cell that happens to span that row.
>
>That's how emacs seems to work when I move the cursor up and down
>among lines of text of differing lengths (although I'm sure
>this is configurable): If horizontal position N exists in line L + 1,
>move the curor from L(N) to L+1(N). If not, move it from L(N) to
>L+1(end-of-line).
>
> _ Ian
>
> - Ian
>
>
>--
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel/Fax:                     +1 212 684-1814
>Cell:                        +1 917 450-8783
>
>
>

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
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
WWW: http://www.w3.org/wai/ua

Received on Monday, 3 January 2000 10:58:13 UTC