Chair: Jon
Gunderson
Date: Wednesday, September 2nd
Time: 11:00am to 12:00noon Eastern Standard Time
Call-in: +1-617-252-1038
11:00-11:25 Keyboard navigation
11:25-11:55 Table rendering and navigation
11:55-12:00 Action items and plans
Denis Anson
Kitch Barnicle
Harvey Bingham
Daniel Dardailler
Jon Gunderson
Markku T. Hakkinen
Ian Jacobs
Scott Luebking
Review Denis AnsonAnson'ss E-mail about chunk navigation
Update working draft guidelines on navigation and table discussion
JG: Denis and Scott on keyboard
DA: We need a third concept. Point of regard. Where in the document are we looking
An attention point.
When I read through the document, most of the information is in hunting for information. Keyboard searching. The other concept is browsing. Searching
JG: Does navigate by header by header and hieracichal navigation address this
DA: If you collapse the document by header some of the information information
HB: It would pick up titles
DA: Moving through the document in chunks, some type of block markup. Use control over the size of the chunk the user moves through the document.
HB: Similar to IE directory expansion and contraction
DA: Except that the information does not fad in and out
User feedback to the chunk size
JG: Does this relate to the Web TV approach
KB: Is the chunk relative to the size of the document, what size
DA: How you would indicate the size, not related directly to size. Should be transparent to the user
HB: A query size of block size needs to be set by the user
KB: No matter what block size the could be great distances between blocks
DA: Logical page design would have some concept to distance
Part of heirachical navigation is reducing temporal timing
JG: Timing issues, can you adjust the timing
DA: No way on the macintosh
JG: Daniel and Ian
IJ: There are some logical level: paragraphs and quotes
DA: List items
HB: One of the things available is the document object model to extract logical blocks of information
If he user wants to know what is on this header level they can get information
DA: For the typical information
JG: the other issue
DA: Point of regard
Not just collapsing document to display a certain structure
I think that I suggested for a visual display or auditory display
If my point of regard would be
JG: Give an example
DA: If you use an up paragraph
Some sort of auditory cue for chuck size
When you change chuck size, feedback on chuck size changes
KB: On demand summary information
JG: Screen reader issue
Non mouse users are the main benefit
SL: What are the chunks that user changes
DA: Users need to know what
SL: User needs to know the listing of the tags
Jumping through the page and stopping at each of the tags
Announcements when people transition into forms
I don't know if a chuck approach works for a list
Maybe you need different sets of commands
DA: You move through paragraphs and then enter a list. user could change to list chuck size
SL: Paragraphs inside of lists
HB: Nested blocks of information
SL: What a new block start
When you are navigating through blocks, jumping to bodies of text
DA: Yeh
SL: You want to jump to the end of the list
JG: Concept of blocks of text and graphics The primary need is for people who don't use the mouse.
SL: Could be looked as a scanning method.
DA: I am not a mouse user
SL: I would stay away from the term "not" mouse user
JG: Web TV stuff connected. Level button.
DA: Do you think it would
JG: where are we going
KB: Who does this compare to hierarchical view
different, extension, replacement?
DA: Hunting verses browsing issue
JG: Action Item
Review what Denis has written
Time next week for the chunk navigation
IJ: In current user agent guidelines: element is designed
JG:
HB: Comments on current tables
Simplistic table examples, do not deal with spans
Dave ragett is a series of little chunks and that the information is related to it's a position
JG: Any body not seen current guidelines
DA: Serialize tables by rows and columns. Point of regard stays the same and then change rendering of the table by rows and columns
SL: Capabilities to navigate row by row or column by column
DA: If I had a table serialized, would you not scroll the table
HB: Which way to jump and how far
SL: In my test browser I had a jump function
DA: Why would I want to re-render a table. If you are visual you would want to maintain point of regard
SL: Somebody who is visual would not want serialized tables
JG: Learning disabilities
KB: Jumping distance and reading entire rows and columns. Table cells often render cells are on more than one line.
SL: Is this tied into the learning disabled. People who are visually impaired are relying on the table being spoken.
DA: Some people want to combine
HB: Other issues:
Summary information: value of "summary" attribute should be available
The structural part is important
DA: The purpose is something the author needs to do
HB: The structural information can be calculated from the text
Spanning tables
SL: One of the ways you can deal with this is having a span reference.
JG: How does it do that?
SL: Additional information on spanned cells. Keyboard navigation to move and return from spanned cells
Really need to have individual cells for navigation of cells for navigation
JG: Setup a structure
HB: My own rendering has
Internationalization issues
IJ: Internationalization orders?
HB: Are guidelines need to be sensitive to language issues
I would like to have a feature for user to ask for varying levels of cell information.
DA: Cell positioning can captioning information
SL: If you just want to do a serial reading
DA: Tables information be part
JG: Tables using TH and TD
SL: Tables are used for formatting. Tables that are use SPANS and Number of incomplete cells is higher for layout tables. this may