operational concept for table browsing

Al Gilman writes:
 > I think I need to articulate some of the assumptions I am
 > operating under.
 >
Good start-- I'll add things in to your original message below:
 > One is that, while it is well and good to talk about how one
 > would do a full readout of a table under different sub-class
 > hypotheses, that interactive browsing of the table is more
 > critical to successful use by speech users.

Agreed-- interactivity is essential.
 > 
 > I have been assuming that HTML needs to have enough semantic
 > content to fully support the following operational requirements
 > for table browsing.
 > 
 >      - Each operational requirement is followed by an assessment of
 >      what is felt to be the flow-down to change requirements in
 >      HTML.
 > 
 > 1.  Cell focus.  The user needs to be able to focus on any
 > individual cell.  That means that the content of a cell can be
 > read out in entirety without interference from content from
 > outside the cell.

Including the ability to read cell contents where the contents span more than
  one line of the visual display.
The fact that table cell sometimes span many lines of a visual display is a
  formatting artifact that is  a consequence of the constraints of the display
  width etc.
and the seech user should not be penalized for that.

 > 
 >      - This is adequately supported in the HTML.  It may require
 >      some enhancements to communication between browsers and
 >      access adaptors.
Yes-- though there is a notion of a "table cell"in HTML, browsers expose this
       minimally if at all and most screenreaders are completely unaware of
       the concept.

 > 
 > 2.  Cell navigation.  The user needs to be able to move the cell
 > focus around in the table.  The minimum capability is discrete
 > stepping through the cells independently in row and column
 > dimensions.

Let me add a few:

1) Before starting to navigate the user needs to have an idea of the table
  dimensions --number of rows and columns.
If a cell has an embedded table, the user needs to be alerted to that when
  dimensions --number of rows and columns.moving to that cell.

row and column spans are an interesting challenge.

Given knowledge of the table dimensions the user needs to be able to navigate
  dimensions --number of rows and columns.either using relative movement (left
  dimensions --number of rows and columns.right up down)
or using absolute  goto movements ie goto cell i,j
 > 
 >      - This is adequately supported in the HTML.  It may require
 >      some enhancement to the command repertory of browsers.

Columnal movement is typically hard in today's HTML since it has such a strong
  dimensions --number of rows and columns.row-oriented bias.
Again most of the enhancements here need to come from the user agents.
 > 
 >      - Enumerators use for row/column coordinates may be
 >      a topic for styling language.  Go-to-cell by coordinates
 >      may be supported but is beyond the minimum requirement.

I'll leave the requirement/optional nature of goto open-

 > 
 > 3.  Cell explanantion.  The user needs to have the option to be
 > presented a definition of the variable that the cell contents
 > evaluates.  Compare with the colloquial "If that's the answer,
 > what's the question?"  This is analogous to the normally-hidden
 > cell formula in a spreadsheet.
 > 
 >      - This requires new provisions in HTML.  The axis/axes/abbr
 >      innovations now in the 4.0 draft are one design to support
 >      this.  This design is open to further discussion.  But changes
 >      have to come with convincing expectation of higher performance
 >      and low impact.

In addition, many tables are not meaningful unless the user has the ability to
produce customized renderings where these minimally include speaking a cell
with its row/column headers and in the ideal world include renderings of the
form
"Total population growth in %s was %s " cell (i,2) , cell (i,1)

-- 
Best Regards,
--raman

      Adobe Systems                 Tel: 1 (408) 536 3945   (W14-129)
      Advanced Technology Group     Fax: 1 (408) 537 4042 
      (W14 129) 345 Park Avenue     Email: raman@adobe.com 
      San Jose , CA 95110 -2704     Email:  raman@cs.cornell.edu
      http://labrador.corp.adobe.com/~raman/        (Adobe Intranet)
      http://cs.cornell.edu/home/raman/raman.html    (Cornell)
----------------------------------------------------------------------
    Disclaimer: The opinions expressed are my own and in no way should be taken
as representative of my employer, Adobe Systems Inc.
____________________________________________________________

Received on Wednesday, 1 October 1997 12:26:55 UTC