W3C logo Web Accessibility Initiative (WAI) logo

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


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


Jon Gunderson

Denis Anson

Kitch Barnicle

Charles Oppermann

Charle McCathieNevile

Cathy Hewitt

Scott Luebking

Paul Adelson


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.


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.


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


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.

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.