Minutes from 1 August 2002 telecon (thanks Andi!)

Present:
jason, gregg, andi (scribe), ben, bengt, loretta, john, avi, eugenia, lee, preety kumar

Regrets:
Wendy, Gian, Matt, Paul, Doyle

jason - success criteria for checkpoint 5.2. Need stronger backward
compatibility requirement at level two.
lee - Prefers to limit backward compatibility to one level previous
version. Lot of engines for AT are IE. Some are starting to swing over to
Gecko format. Drive people to upgrading their software for the free stuff.
JAWS will use latest version of IE that it finds on the system.
jason - level 1 specify baseline, level 2 should be more stringent, level 3
goes beyond that. Open as to what these should actually be.
john - main difference in two proposals is that one is keyed to timeframe
something has been available and other is keyed to version level of
software.
jason - sets minimum technological threshold. Content must still work below
the baseline but may not work optimally. Has impact on what standards and
technology people rely on. Need objectives for what we are trying to
achieve at level 2 then work out criteria to achieve those objectives.
lee - FLASH can be accessible if use Window Eyes. What Windows platform
does this require? Windows 2000 or XP? or Windows 95/98?
john - most developers use version numbers, not timeframes
gregg - vhs won over Beta because there was more of it. Worry that we are
defining compatibility in terms of what there are the most of.
lee - primary drivers are IE and Gecko. If we design specifically for IE,
there may be problems down the road. JAWS, WE, and HPR all use IE. If also
works for Gecko, covers most of the rest.
gregg - some features exist in one but not the other. If the criteria is it
must work in both, these types of features would be excluded.
jason - could clarify that there have to be "interoperable" features.
gregg - so longdesc would be illegal
john - HPR and JAWS support it.
gregg - HPR and JAWS don't count because they are both on same engine
lee - Gecko supports longdesc
lorreta - it will support it when it comes out. but requirement is that it
be supported in the previous version too.
loretta, andi, and john agree that it is easier to attract versions than
timeframe
lee - can we say "engines" instead of "versions" to avoid possibility that
two options chosen are JAWS and IE because JAWS uses IE engine
jason - proposal worded as "component" because it depends on where the
feature is implemented
gregg - need to determine if can't figure out how they would do it.
lee - benefit is to get people to stop supporting just IE in their designs
john - what does below the baseline mean?
jason - level 1 criteria talks about technologies "above the baseline".
These are technologies you may use but are not relying on. Level 2 talks
about the technologies you are relying on.
andi - below the baseline is what is "required" to use the site
gregg - level 1 page is still usable if technologes that are not in the
required list are not available. level 2 says that the technologies you
choose for the required list have to have been available in at least two
implementations for at least two versions.
gregg - how do you get two independent implementations of FLASH or other
proprietary implementations?
gregg - what is the reason for having two implementations?
lee - could provide note on third party proprietary technology
gregg - that's going backwards
lee - want two user agent engines
loretta - assume the reason we would ask for two implementations is to
ensure that specification is adequate. PDF has public spec. GO Script
supports it but it is not accessible.
jason - requiring that technologies you are relying on are public and well
supported. Combination of interoperability and backward compatibility help
ensure that you have a wider variety of users and devices that will be able
to access it. Gregg's question is what is the rationale for that type of
requirement.
jason - AT support is covered in another checkpoint.
loretta - what was goal of this checkpoint
jason - trying to avoid lock-in to some particular version of software
gregg - what is it that we are trying to address with this checkpoint?
Level 1 is just letting people know what you require. Need to keep the word
"accessibly" in there.
jason - worried about using the word "accessibly". These guidelines define
what "accessible" means. 5.3 covers the AT problem
gregg - then what is the purpose of 5.2? Backward compatibility. What does
two independent versions have to do with backward compatibility? What does
defining your minimum requirements have to do with backward compatibility
john - level 1 does talk about backward compatibility
gregg - title must be trying to get at something different.
john - level 1 is to have a baseline and state what it is. level 2 is that
the baseline has to have been available for at least two versions
jason - don't want to require any level of backward compatibility at level
1 but ask that people be concious of what they are requiring.
jason - level 2 is to place stronger restraints on the required list
gregg - proper title might be "technologies required in user agents in
order for content to conform with guidelines are declared and commonly
available"
gregg - this is the first checkpoint where we have required metadata or
policy statement on the site
jason - before we put it on level 2 because checkpoints were judgement
based
gregg - will post re-write of success criteria
pk - what is meant by "versions"? are these major releases like 4.x to 5.x
or would 5.4 and 5.3 count as two "versions"
gregg - how will page authors know how long features have been available or
which features are in which one?
gregg - how important is this? If we don't have this in here, will pages
not be accessible?
lee - want to get users to upgrade their free stuff.
john - costs money if they have to upgrade their hardware
jason - ultimately implementors will make a decision about how far back
they want to go.
john - we have responsibility to help people figure this out
jason - even if we use time period instead of version, somebody still has
to provide the information.
lee - don't know anyone who keeps track of technologies based on time frame
but there are people who keep track of it based on versions.
jason - are we any closer to resolution?
gregg - think we have a better title. Need to post notes to mailing list.
gregg - need to examine what we are trying to achieve and ensure that
success criteria that achieve that and are not treating a symptom.
lee - think we have done it when we say "two implementations". will open it
up to force developers to design to more than just IE

gregg - questions about second topic about how we pick success criteria
gregg - decided that success criteria have to be things that are testable.
can we further state that this is machine testable or HIRR - high inter
rater reliability; i.e. most raters who understand the issue and the
measure would all say the same things
avi - this gets tough with 4.1. trying to amass some things that would be
testable.
gregg - level 1 and level 2 would have to be applicable to essentially all
content on most all types of sites, all level 1 criteria have to be met
before anything in level 2 can be claimed.
[group consenses]
gregg - level 3 is for people who are pushing ahead and does not have to
apply to all types of sites
jason - if we have a lot of these that don't apply to most sites, we should
question whether or not we should have them
john - isn't it possible to claim a particular level of conformance for a
particular page on a site
gregg - yes, but that's not how they usually get applied
avi - technical standards fit this but may not apply for content type
checkpoints (4.1 et al)
[gregg will post modifications]
avi - one of challenges is how to write 4.1 in a way that is reasonable and
pragmatic. May not be reasonable to have to make all of your text comply.


Andi
andisnow@us.ibm.com
IBM Accessibility Center
http://www.ibm.com/able
http://w3.austin.ibm.com/~snsinfo

Received on Tuesday, 13 August 2002 18:35:03 UTC