Chair: Jon
Gunderson
Date: Wednesday, August 26th
Time: 11:00am to 12:00noon Eastern Standard Time
Call-in: +1-617-252-1038
11:00-11:25 Review and discussion of table WD Revisions
11:25-11:55 Discussion of keyboard navigation strategies
11:55-12:00 Action items and summary
Jon Gunderson
Kathy Hewitt
Kitch Barnicle
Scott Luebking
Daniel Dardailler
Denis Anson
Harvey Bingham (11:30)
Jim Allan
Markku T. Hakkinen
Jon Gunderson will send a corrective message on F2F dates
Kathy Hewitt will talk to Web TV team about human factors research in the Web TV keyboard interface
Review current WD keyboard on keyboard issues and will report back to telecon next week. Keyboard group includes Denis Anson, Scott Luebking, Kathy Hewitt
Next telecon will discuss table rendering and navigation.
Kitch Barnicle: Requested future telecon topic on frames access
JG: Announce the F2F after CTG conference
Announced the weekly telecons
DA: Navigating documents via the keyboard
Concerned about third
Document can be modeled as a tree, but most don't understand
Arrow keys as navigation keys
Meta keys used to define levels of document structure navigation
People would
JG: Selection and focus definitions
Part of we is to define selection and focus
DD: I don't think there is a need to provide more detail
We all ready have keyboard
Documentation should describe the model
Plateform issues makes it difficult to specify certain keys
JG: Hieracherical navigation
DD: I think we should go beyond what we have
SL: One of the things to focus on characters and words may conflict with screen readers. Users may want to use th
DA: How can you navigate eefficiently using screen reader
KB: We still have a blur between assistive technology and the browser
SL: Additional aspect with the arrrow keys when navigating nested list. They want to go to next list or to a sub list
DA: The document tree structure is not what the user thinks about.
SL: How does the user make choices about sub lists and next list items
DA: Use a modified arrow option to go down a sub list
SL: Notion of level may be a difficult concept for some users
Changing levels is confusing
KB: Seems like we are getting to a implementation model
SL: One of the things I though use full, would be a system that would jump from block of text to block of text. The screen reader has difficulty reading from block to block, but good at reading with in a block
DA: Who defines what a block
JG: There are block structure within HTML
DD: There are in-line and block level elements.
DA: What I would like to see, what is a block. If you had a large document, you may want to move through in big chunks. Move at the the level of interest, but all of the elements are visible.
SL: Would people create such large document
KB: We have a block level specification.
DA: When you say expose the entire document
If you display all the information there is context
SL: A header followed by text that there would be greater context.
KB: Concerned about consistancy
KH: We are working on IE 5.0 we will have similar model as the current IE 4.0. I am looking a IE 6.0 keyboard model, using the Web TV model. Authors do not use HTML correctly.
DA: Do we want to encourage correct design?
KH: We need to encourage correct design, but also look at what people are actually doing
SL: One way to look at it to see how people can access what is there.
KH: When you are creating pages I could use <BR> to make blocks.
JG: What about an expanded a search function
SL: Can their be a more abstract concepts, people do not understand structural elements
We could caterize headers and elements in to units that people could understand
DA: It does sort of makes sense, but people don't know element names
SL: A more general concept
DA: Move a page of text
KH: The easiest way is use a page down to move a screen at a time, there may be a way to use page down to move an element at a time
SL: A sighted person may look a pages, but they are looking a paragraphs
KB: There are two issues: Speeding up moving through the pages and reading functional units. When you jump, you lose context.
DA: Need access not to just links, but also content
SL: Some people just want to jump through the links,
JG: Keyboard navigation
Heircarchally
Block by block
Poor design
DD: We have keyboard access, moving beyond to implementation
SL: Keyboard access
DA: I was not intending a specific implementation
HB: Would like users to not need to learn a new navigation strategy for each ne browser
SL: There may be no way around that....
HB: I would hate to navigate
JG: We do not want to impose knowledge of HTML
DA: Able bodied persons would use keyboard commands
SL: Usability studies that keyboard is more efficient
DA: Agree, we are not working on just a disability issue. We want to be transparent
User agent be able to interpret commands from 3rd party assitive technology
If the UA by passes standard operating system
JG: We look see if have language I/O APIs
Web TV interface
Move block by block
Search functions
DA: we should pursue
SL: As there any research on Web TV research
KH: There probably is, I can followup
SL: Count, moving by a count
HB: If a list of 17 items, skip or move to?
SL: I was thinking of relative
KB: A user adjustable jump value
JG: Action items