16 May 2002 WCAG WG Minutes

Attendees:

Jason White
John Slatin
Gregg Vanderheiden
Cynthia Shelley
Andi Snow-Weaver
Ben Caldwell
Paul Bohman
Bengt Farre
Gian Sampson Wild
Katie Haritos-Shea

Regarding Gregg's proposed conformance scheme....

jason - are there any issues or criticisms?
gregg - comments to list. Lisa said she preferred the modular approach
because couldn't discriminate based on disabilities.
gregg - followed up with note asking for more information
cynthia - intermediary modular approach where there would be groups of
checkpoints. Each guideline would be a module. Could claim a level of
conformance for a particular module.
jason - claim at a different level potentially for different checkpoints
provided you have reached level one for all checkpoints
cynthia - Lisa's concern is that the success criteria she is most
interested in did not make level 1
gregg - but they wouldn't make it in a modular scheme either
jason - in last discussion of modular concept, there wasn't much support
for it
<idea is modular confomance similar to XHTML>
cynthia - what we are proposing may actually achieve the same end. Lisa
would probably like some of the cognitive success criteria to get to level
1. Can't do this under current criteria of applying to all sites and
testable.
gregg - wait for lisa's response with regard to benefits of modular
approach.
cynthia - for adoption, incredibly important that for pri 1 everything be
broadly applicable and testable
paul - nothing in current draft for cognitive that is testable?
cynthia - some things are but nothing having to do with writing style
jason - some of the criteria say simply "you've implemented it to the
degree you think is appropriate"
jason - for some the criteria is to have considered and honestly worked on
it

<gian joins>

paul - do we have priorities for every guideline or every checkpoint?
gregg - success criteria for every checkpoint. level 1 success criteria for
every checkpoint required to claim any level of conformance. Once level 1
is achieved, higher conformance levels by checkpoint can be claimed.
gregg - does group agree that higher level of conformance can be claimed on
checkpoint basis
paul - sounds modular
gregg - yes, once you reach level one on all of them

<group agrees>

jason - W3C developing technologies for reporting conformance in meta data.
software will automate the reporting of the conformance claim.
paul - sounds like a good approach
jason - basic strategy seems to work
andi - no need for level 4
gregg - advisory will automatically go into non-normative information
block. Normative only views will not include these at all. Making them a
"level" requires that they be "objective". To re-write them to be
objective, would turn them into something that is not really
understandable.
john - the point of advice is that it is advice, not an injunction
gregg - "write simply" would have to be turned into something that is
measurable
gregg - maybe some of them could be turned into something that is testable.
cynthia - issue about it disappearing not as big of a concern because
success criteria at other levels require that you have looked at the
advisory recommendations.
jason - requirements become more stringent as you go to higher levels

<katie joins>

gregg - need to get issues with conformance schemes on the table as soon as
possible
gregg - more research being done. More ideas on making web sites accessible
to people with cognitive disabilities will become available.

Guideline 5 issues

cynthia - goals were to 1) simplify the language, 2) acknowledge the things
that are assumed, 3) make sure they are testable
gregg - looking for overall statement about the issues this guideline
encompasses
cynthia - trying to make explicit the tension between backward
compatibility and moving forward. "use the right stuff and use it right".
One deals with backward compatibility, one deals with accessibility
features, one deals with using technologies according to specification.

<cynthia reads proposals from draft>

andi - like the idea of allowing the author to specify the baseline browser
assumptions
gregg - issue of testability. Does it have to be defined in meta text?
cynthia - could be text or an icon
gregg - could claim compliance by saying support HPR. If web site
accessible using HPR or own custom browser, it is accessible.
cynthia - can't think of any other way to write a baseline that won't be
outdated in three years
gian - how about "support browsers that were written within the last three
years"?
cynthia - which browsers?
jason - requirements of vendor neutrality. can't list someone's browser
without listing all of them. seen to be favoring one vendor's product over
another one
gian - what if you say support particular browser works with IE, have to
work with last three releases
cynthia - so you have to support IE3?
cynthia - these are the types of issues that make blanket statements like
that impractical
gian - what keeps someone from saying they don't care about the 30% of
users who use Netscape?
jason - checkpoint about using technologies according to specs will
probably catch most of those problems
cynthia - there's a requirement to use things according to spec, make them
backward compatible, and use newer technologies that support accessibility
cynthia - these three things are often impossible to do at the same time.
gian - if author comes to this guideline and says "don't want to deal with
issues of backward compatibility so I'm designing for NS 6". Can they do
that?
cynthia - would fail backward compatibility and use technologies according
to spec
cynthia - doesn't mean it would only work in NS 6
cynthia - for example, if say baseline is html only, has to still work if
scripts or CSS are turned off
gian - what if baseline includes scripts, .... ?
cynthia - will pass this checkpoint but may fail other checkpoints such as
"use technologies that support accessibility"
jason - thinks other checkpoints will catch most things.
cynthia - normal for web authors to exploit new features but still support
older browsers. should be concious decision
gian - if someone says IE4 is baseline. if find something that doesn't work
in IE4, then may just decide the baseline is IE5.
gian - people with disabilities tend to have less ability to get latest
technology. don't see this changing in the near future.
cynthia - where does the responsibiltiy lie? maybe not with the user. maybe
the government has to take responsibility to make sure people have
technology that affords greatest accessibility. shouldn't fall onto the web
author.
gian - agree that it is a government policy issue but don't see it
happening.
cynthia - web sites don't have unlimited funds either to do the extra
development
jason - personally have problems with something that requires certain level
of backward compatibility at level 1
gian - not hung up on this being level 1
cynthia - what if my definition is level 1 and we have more stringent
requirements at level 2
jason - what would you put in level 2
gian - could have level 2 as html and css only, level 3 could be html only
gregg - but we agreed to have no technology specific things in WCAG 2
cynthia - could word it as WCAG 1 assumptions
cynthia - maybe we should take this offline
gian - can't take an action item for another couple of weeks
gregg - compare to similar success criteria in other checkpoints
cynthia - in simple terms "make a concious decision and document it"
gregg - allows people to not fetch your pages if they can't access it.
jason - because technologies change so much, can't think of anything else
to put there that wouldn't go out of date.
jason - can argue about what should go in level 2 and 3
jason - only thing I can think of for other levels is length of time
available, broadly available. Don't know how testable things are.
cynthia - time requirement is testable. version numbers are a bit trickier.
jason - level 2 might say "implementation has existed for certain length of
time, supported by AT for certain period of time"
cynthia - emacspeak example. available for a long time, good function, but
not available to many people
jason - need an action item to work on level 2
cynthia - prefer that editors incorporate changes into next draft and
either attempt level 2 definition or provide description of what we think
level 2 should encompass
gregg - need to get everyone comfortable and then post public draft
gregg - as part of testing process, have to look at what we are proposing
here. Look at success criteria - is this necessary and is it sufficient?
gregg - need to be skeptics. in particular, need web masters or people who
are part of technology companies to look at these.
gregg - want to get big problems on the table before publishing.
jason - over last several meetings, discussed reworking conformance
section. Can do this based on Gregg's draft. Also discussed reworking some
checkpoints. Need to get new drafts in front of working group, do editorial
work to get draft ready for publication.
jason - WG members need to thoroughly review cynthia's proposal. Raise
issues and suggest fix on mailing list.
gian - volunteered for future action item to write the level 2 and 3
success criteria for backward compatibility checkpoint.

Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo

Received on Thursday, 16 May 2002 18:08:45 UTC