Minutes from Wednesday, 18 November 1998, Telecon

WAI UA Telecon for November 18th, 1998 

Chair: Jon Gunderson 
Date: Wednesday, Novemeber 18th 
Time: 12:00 noon to1:00 pm Eastern Standard Time 
Call-in: (+1) 617/258-7910

Agenda
12:00-12:20 Categorization of techniques by priority ratings and
implementation
strategy
12:20-12:30 Rating of guidelines by priority
12:30-1:00 Table linearization and navigation 

Attendance
Jon Gunderson
Denis Anson
Kitch Barnicle
Charles Oppermann
Charle McCathieNevile
Cathy Hewitt
Scott Luebking
Paul Adelson 

Regrets 
Ian Jacobs 
Wilson Craig

Action Items and Conclusions
DA, CO, CMN: Will submit example of techniques to the UA list related to table
access by the blind, this is to expand our current discussion from
linearization techniques

Discussion of categorization of techniques should be limited until techniques
document becomes more stable. Limit references to categorization to simple
statement of personal preference for people to note but not comment.

Two levels of categorization discussion will continue after document becomes
more stable.
Looking for people to volunteer to contribute content to working draft and to
maintain issus list.

Minutes
JG: New categorization of techniques
Categorization of techniques
Priority is need of users, second is direct versus indirect technique
If AT is not available, then must be directly implement
Generally want both direct and AT access
Things that are generally needed should be provided by agent, so not
redeveloped in each AT product.
CO: May muddle the situation
Guidelines should say what developer must do
Give a prioritized list
CMN: Must do all of the things relative to your particular product
Real Player is as much an agent as IE, 
Developers can select guidelines that are relevant to their product
CO : Direct versus compatible issues: how does this change between types of
agent
CMN: It doesn’t. But not all agents need to implement all guidelines because
not all are relevant. For example, don’t need to manage tables in RealAudio,
since they never get them.
CO: Compatible may not be possible in real world
Reason for reorganization
Old document didn’t clearly define what must be done natively or compatibly
How do we group under direct or indirect
If we take approach of leave it in for now, then notice that everything is
indirect, can dump that category
Perhaps the problem is that this is secondary priority, not primary.
If access feature is native to the device, then should be directly implemented
by the agent. If not, then should be compatible
CO: Should Mac browsers have to have keyboard access?
SL: For developers, what do developers need to understand to make the browser
accessible. The guidelines should be specific enough so that non-access
developers can understand them, but not limit their creativity. Guidelines
should be more precise in specific issues, so developer can follow guidelines
to make browser accessible.
Critical issue is that information be understandable to developers who are not
conversant in disability issues.
Perhaps guidelines can be in major categories, with subsections
JG: Chuck suggests that guidelines should represent developer priority rather
than user needs.
CO: In almost always be linked to user needs
Prioritized to list of what developer must do
Developers want to be told what to do, what will have the biggest impact on
users.
DA: Priority 1 items must be implemented or have locked out some users
Priority 2 items should be implemented to make access convenient
Priority 3 items make access "nicer," but not easier
CO: Priorities give both priorities and method of implementation
Priority 1
Ordering might be a secondary priority for implementation
Given a list, developers may implement just top 3
Very easy items might be implemented even when down the list
"Low hanging fruit"
Items that can’t be implemented currently might be in design loop for future
development
Should target major, mainstream browsers first
Then come back and pick up marginal browsers
Content rendering things (Real player) should be part of release 1.
Telephone browsers, etc. need not be in this release.
JG: Better definitions of the guidelines may prioritize for users and for
developers at the same time. Later, may deal with specialized browser
later, or
leave that to developers of specialized browsers.
Tables
Guideline suggestion
CO: Control over display of tool tips. Does CSS have anything about display of
alt or tool-tips.
Can select image based on presence of title, but not on content
CO: Propose: display of tool tips can be distracting for those who don’t want
tool tips popping up.
Should UA offer a way to turn off tips?
Tool tips are like extra status bars, so could be turned off as a UA exercise
Linearization of tables
Much discussion on the list. Consensus that it is important.
Linearization is visual presentation of table structure markup
Need to provide context in non-visual format
90% are used for positioning, not for content
Need to plan for proper use, where there still are problems
Even in navigation, can be useful
Implementation?
Should it be native or compatible determined later.
Does control have to be at a cell level?
Unit of information in a table is a cell
Why would you give focus to something doesn’t take input?
Point of regard needs to move by cells, but focus need not.
WinVision 97 provides virtual carat to each cell, 
May want to provide navigation to tables separate from linearization
Is table linearization a technique or a guideline
Guideline should be to provide cell level access, within context of the table.
Linearization is one of the ways to do this.
Should not be thought of in terms of just screen readers
CO: Folks from CAST have browser that does cool rendering based on IE. It is a
specialty browser for people with special needs. (David Rose others)
JG: Can some members talk about other methods of table access for low-vision,
no-vision, or learning disabilities?
Looking for people to contribute to sections of the guidelines. Call Jon to
talk about it.
List on UA page of sections being contributed to.
When will guidelines be released?
JG: When things become stable.
CO: Lock down document so no new features are added.
JG: Volunteer organization, so can’t allocate resources to task, must be based
on input from volunteers.
CO: May be time to restrict new guidelines in this version, move on with this
version of document.
JG: List of priorities on UA page
May be able to come to resolution on guidelines and priorities.
Need somebody to maintain the issues list.
Jon did that but doesn’t have time now. Need a volunteer. Provides one
place to
see what has been resolved, and what has not. 

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Thursday, 19 November 1998 09:33:28 UTC