RE: A look at tables

Denis,

I agree with you 100 percent about the AT providing a standard API to ATs.
This should be done through the DOM and not an OSM. The concept of "where
you are" within a table would depend on navigation which is largely
dependent on ths AT.

Asking an AT to provide what you ask is fine however the automatic
determination of where to move you next and in what context based on a
keyboard navigation scheme is too much to expect the user agent to do. Also
determining what the cell is above and below could be determined by the
table embedding level is also a hefty burden. Much of the basic information
you are asking, save determining what the current cell is, is provided in
HTML 4.0.


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


Charles McCathieNevile <charles@w3.org> on 12/29/99 08:24:58 PM

To:   Denis Anson <danson@miseri.edu>
cc:   Richard Schwerdtfeger/Austin/IBM@IBMUS, Ian Jacobs <ij@w3.org>, Scott
      Luebking <phoenixl@netcom.com>, w3c-wai-ua@w3.org
Subject:  RE: A look at tables




Graphic user agents already need to calcuate how the columns of tables line
up, in order to render them. SO it would make sense to require that graphic
user agents provide the ability to go up and down columns, which is one of
the most difficult things to do at the moment (as far as I know emacs/W3
and
Amaya are the only user agents that normally make that easy although many
authoring tools with a user agent function can allow it - Netscape Composer
for example). Finding headers probably should be done by the rendering
engine, so where that is an assistive technology it should work it
out. the tablin tool should be looked at more carefully in this regard.
Charles McCN

On Mon, 27 Dec 1999, Denis Anson wrote:

  Rich,

  Even assuming that the AT must provide support for tables, the user agent
  must provide sufficient information, through some sort of standard API,
to
  allow the AT to navigate tables.  If the AT is stuck with reading the
table
  off the screen or off-screen model, we have all of the current problems
with
  tables.

  I think that, at a minimum, the AT must be able to ask for the contents
of
  the current cell, the headers for the current cell, and to move a Point
of
  Regard or some other locator to the cell to the left or right, and the
cell
  above and below.

  If this is too great a burden for the UA to support, how will it be any
  easier for the AT to do?

  Denis Anson

  -----Original Message-----
  From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
  Behalf Of schwer@us.ibm.com
  Sent: Monday, December 27, 1999 10:56 AM
  To: Ian Jacobs
  Cc: Scott Luebking; w3c-wai-ua@w3.org
  Subject: Re: A look at tables





  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






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

Received on Saturday, 1 January 2000 17:17:36 UTC