1 February 2001 WCAG WG telecon minutes

Summary of action items and resolutions

Participants

Jason, Gregg, William, Charles, Loretta, Cynthia, Marti, Dick

User Agent Capabilities

/* CS minutes */

JW There is a checkpoint that requires backward compatibility. How do we determine degree? What is the impact on conformance?

Charles: tracking UA capabilities. When can we reasonably expect everyone to have a UA that does something? When is the feature so prevelent that we can stop supporting the alternatives? If you're still using Win 95, you are on your own to some extent. If you are still using DOS, is it reasonable for you to expect the same level of supprot

Jason: There is a time at which a feature has been implemented enough that authors can expect it to be supported. And, there is a time at which it is reasonable to stop supporting a workaround for the missing feature.

William: When does assistive tech qualify as being a user agent?

Jason: Still under consideration by several working groups. Definitions in some guidelines assume for purposes of those guidelines that certain assitive techs are part of UA. We should wait for this decision.

/* CMN starts taking minutes.*/

JW there is a difference between thie time when a feature is avilable to people, and when it is reasonable to expect that people are usng it and older versions need not be supported

WL When does a user agent become assistive technology or vice versa

JW It is something that guidelines groups ned to consider. Probably for the glossary group - in some cases a user agent is considerd to include Assistive Technologies.

JW There are different proposals. One of Charles' was to set some criteria based on availability of user agents. Another approach was to decide on a case by case basis. Further ideas - it could be dealt with in priorities mechanism - if feature X is available then the priority for doing something goes down.

WL Is there an implied "if it doesn't work on lynx it won't qualify"?

CS I think it has been implied in the past but I don't know if that is a good basis

CMN It has been considered that anything supported in lynx is readily available

JW Or if there is something people can download from the Web

CS In the industry the definition is whether it is available in the current version of IE and Netscape

GV Problem is that not all people who need a tool know that it is there. I worry about things that are not options in "standard browsers". We need something more than "if i isn't in the major browsers" - maybe it needs to be whether you can find it in any screen reader. If we assume people know about a tool we need to create a mechanism that let people know about it.

MM US ADA Section 508 says that if you require a tool you must require a link to the tool.

CS Both plugins and ?? have an auto-download control that tells you where to get it.

WL It is hard to find the shut-off feature.

JW Concern: Choosing any particular user agents as defining feature support. This could violate W3C vendor-neutrality. But it should be possible to set criteria independent of naming specific user agents.

CS Could we say top N installed user agents

CMN I don't think so

MM Top 2 or 3 for where in the world

DB Do we have to get specific about browsers, or about features? Could we require people to use scripts?

CMN Yes, I think Dick is right. But at some point we come back to what browsers we are using. This varies in Operating system, in language, in ...

WL How many features are we talking about

CS I think this will come up a lot. If you have to support Mosaic 1.0 then you can't rely on client side image maps. Guess half a dozen features.

CMN There are features that we require - following links, dealing with forms. There is a case that says we should be able to require Javascript

JW What is required is to go through the various features required and name what they are.

WL What about in version 2.0?

JW This becomes relevant in the techniques. If user agents don't support XX then the author will have to provide for a work-around.

CMN Features that are often brought up in this context: Javascript, Java, CSS, server/client - side image maps, frames, tables, animation, ...

JW you can break these down into a lot of little differnces/issues

Matt This is an issue that gets bigger - every tie a new browser comes out we will add to the list of legacy issues. If we set a baseline it may be irrelevant before the document is released.

DB I don't think we should be saying that guidelines assume a particular browser. We need t odecide what priority problems are, and then look at them in terms of what is reasonable.

GV One problem is that at some place we will ahve to seperate accessibility from what we think users should deal with. We start mixing priority from accessibility and from what people's browsers do.

JW one approach is "when a feature has been implemented, is publicly available, we think it is reasonable to rely on it". That is one approach to conformance.

/* DB minutes */

Dick Brown: We shouldn't use specific browser versions for the baseline, but rather browser *features*.

Gregg Vanderheiden: Someplace we have to separate what constitutes accessibility and what it is we expect people will do. We've tried to make guidelines what constitutes accessiblity, and we're not going to ask people to do something that's impossible. Doability needs to be mixed back in without playing games with the priorities. Tying it to a browser is a doability issue, not an accessibility issue.

Jason White: We could say when a particular (browser) feature has been implemented ... is publicly available, it's reasonable to start implementing it even though many people don't have it. We won't (challenge compliance claims by) people who implement it, but will discourage (its use). (There can be a) difference between a compliance claim and what we recommend -- different ways of giving flexibility in how people implement the guidelines.

Charles McCathieNevile: Would be nice to have someone volunteer to go through the guidelines and say which require particular features depend on user agents and which don't.

JW: Action item could be: Work through 2.0 and latest techniques to identify user agent capabilities which are assumed by the checkpoints and techniques.

Action DB: Work through 2.0 and latest techniques to identify user agent capabilities which are assumed by the checkpoints and techniques.

Mapping 1.0 to 2.0

Resolved to accept JW's proposal for update to checkpoint mapping -- see JW mail in archives 5.3 and 5.4.

F2F

Reminder: registration open for f2f in March.


$Date: 2001/02/08 16:33:24 $ Cynthia Shelly, Charles McCathieNevile, Dick Brown