Date: Wednesday, September 16th
Time: 12:00am to 1:00 Eastern Standard Time
12:00-12:10 Update on reformatting
12:10-1:00 Keyboard navigation
Markku T. Hakkinen
JG: Discussion time
SL: Keyboard navigation e-mail. Any questions.
HB: Concern about spanning cells.
How do people skip over scanned tables
SL: the way I was approach it that there would be information about the cell being spanned
HB: that's not what is in the HTML
SL: That is subject to interpretation
JG: How is the position feedback to the user
HB: What about the
MK: Should have more consistency
MH: We will not limit ourselves but what the guidelines, we are doing something better
SL: Navigation and rendering are tied together
HB: HTML 4.0 blurs navigation and rendering
SL: I was not sure how to integrate header information
SL: How often to people want to go from the body to the header section. Move up to the header section and move down to the body section.
HB: What types of rules
SL: I think there is a way of talking to about
MK: The information in HTML in there are specifications for cell orientation
SL: The user doesn't need to go to the top for the row information
The header information is rendered in the cell. The user could configure this in their browser.
MK: I don't think you want to jump back and forth
HB: The current linearization provides for that.
MK: Same with a table that crosses 2 pieces of paper.
HB: Want user option to query table coordinates and headers
SL: Depends on the type of tables, should put headers in the cells
HB: I am going to spanning more than row. The user agent my render a compound information for that row.
MK: Hierarchy of titles
SL: One of the suggestions I had was to mark a cell, and return to a previous cell.
Focus on navigation within a body, more navigation commands within a body. Can return to the last body cell.
HB: That there be row descriptions about the column as it changes
MK: What more do you get when you go to the header
SL: What do you get when have multiple headers
HB: The user should not need to remember how big spans are
JG: What about signal should be given to the 3rd party assistive technology
HB: What the end result should be should be specified
MH: We want to know what the end results
KH: The user agent needs from a browser, rather than how something should be implemented
SL: The navigation that is required cannot be handled on a purely keystroke basis
Requiring the person
MH: We will provide information about the size of the table. People want to only know what they need to know and a way to get more information. You need different types of keyboard models for different types of users.
SL: What are core functionality?
MK: There are only three columns.
JG: What about selection and focus
MH: We are
JG: Selection and focus, should they be included
KH: Highlighting or moving the cursor are two different ways to indicate
HB: Some people would like to hide columns or collapse columns. Is that a user control we would like to have.
SL: There might be a way through user navigation.
HB: I am thinking of a magnified window.
MK: I think this would be handy
On a very small screen it would be useful
SL: Gets tricky with spanned cells
HB: For no spanned cells
JG: Keep the headers
HB: Just related to cell distances, how do people know they are gone
SL: Should they be hidden or moved
MK: They should be collapsed
HB: Some information on that something has disappeared
Allow the user to
KH: Windows 98 moving the keyboard focus.
JG: Selection and focus
MH: There is no difference between focus and selection.
If you want to decompose a selection into sub information
You can query images for alt or longdesc
HB: Mark you have given a lot of thought, some
JG: I need to get these topics in my head space
Discussion about collapsing tables:
temporary hiding or collapsing a rows or column
JG: New topics brought up for future telecons