Chair: Jon Gunderson
Date: Wednesday, Novemeber 18th
Time: 12:00 noon to1:00 pm Eastern Standard Time
Call-in: (+1) 617/258-7910
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
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.
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 doesnt. But not all agents need to implement all guidelines because not all are relevant. For example, dont 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 didnt 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
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 cant 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.
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 dont 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
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 doesnt 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 cant 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 doesnt have time now. Need a volunteer. Provides one place to see what has been resolved, and what has not.