9 May 2002 WCAG WG Minutes

Attendees:

Gregg Venderheiden
Jason White
John Slatin
Gian Sampson Wild
Cynthia Shelley
Ben Caldwell
Matt May
Eugenia Slaydon
Bengt Farre
Loretta Guarino Reid
Andi Snow-Weaver

jason - 2.1 status. proposal by Gregg on the mailing list. Some discussion
on mailing list.

gregg - CMN comments - everything should also be operable via a mouse or
via keypad on the phone. Mouse users use onscreen keyboard which falls
under keyboard navigation. CMN thinks all pages should be operable via the
phone but most are already.

gregg - operable via keyboard. issue is what kind of keyboard. even screen
reader users us the numpad for screen reader navigation. text entry plus
"stepping" and "go" function - is this too restrictive? should we require
arrow keys. CMN thinks we shouldn't require arrow keys.

andi - where do we draw the line between browser responsibility and content
author's responsibility?

gregg - depends on technology.

jason - serious problems with anything that ties it to keyboard
interaction. checkpoint needs to be abstract enough. jason proposed success
criteria on mailing list. may have to work backwards to arrive at
checkpoint wording.

gregg - if too theoretical, web masters won't know what it means when they
are actually implementing the page.

jason - technologies, especially w3c technologies, are implementing "these"
already. concerned that if wording isn't right, sends mixed messages to
developers. proposal including "text entry", some kind of "navigation", and
some kind of "activation" is close. proposal should include use of device
independent methodologies provided by the technology being used.

cynthia - does this cover the "event" piece or just the UI piece. i.e.
"onfocus" ?

jason - if "focus" event defined by the technology that is not
device-specific, that is the one that should be used.

gregg - what is definition of "device independent"

cynthia - two floating around W3C. one deals with input devices, one deals
with PC vs. phone.

gregg - have to be able to define it in more than just HTML terms. jason
seems to be getting close to it in 2nd of his two points.

jason - 1st point talks about what makes an event device-specific in a way
that we don't want. if parameterized based on physical state of input
device, it is problematic. i.e. coordinates, specific keys, switch
settings, etc. 2nd point - if logically abstract events don't exist, use
device-specific functions in redundant way.

gregg - what is it that we are trying to achieve or prevent? typing on
keyboard or using an alternate method for typing on the keyboard such as
speech input. concept is all about entering text. has to be mechanism for
moving among choices and activate them. can't do direct manipulation
interfaces because they require eye-hand coordination. also has to be
completely operable with mouse because more efficient for some people.
guideline needs to be more general, then checkpoints can address more and
more devices.

jason - should be possible but not necessary to step through the choices
one at a time in order to activate them.

cynthia - minimum is that you be able to get to everything on the page in a
device independent way. next step is more direct way to get to important
things on the page. is that what you are saying jason?

jason - not necessarily. must be able to invoke any function, do text
entry, and determine what the choices are. need to re-work the proposal.
where technology doesn't allow this to be done in device independent way,
have to provide redundant device specific methods. gregg had some
interesting ideas for level 2 and level 3 success criteria.

<loretta leaves>

andi - what if technology doesn't support more than one device-specific
input method

cynthia - like a kiosk with only a touch screen

jason - so have to rule out technologies that only support one type of
input device. need to be careful to distinguish between programming
technology the author has control over and the hardware the page might be
displayed on.

john - asking that authors do whatever is in their power to ensure that
their content is rendered in as many ways as technology allows.

cynthia - unclear about whether wcag is concerned with independent input
devices or independent rendering devices

jason - both but this checkpoint is about independent input devices

gregg - think problem is that we are trying to be generic in this set of
guidelines. hard to do that with this one. "step" and "choose" is the
simplest way to figure out what the choices are and choose one. jason's
idea good: "text entry" plus mechanism to identify all the things you can
do plus a way to invoke them. but what if the way you do it is with a
mouse? breaks.

jason - if working with mouse, can't identify what the events are. no
discrete list of them. response is different depending on coordinates of
the mouse click. events are hidden - no way for AT to list them.

gregg - what if have screen full of buttons but they can only be activated
via a mouse. so if publish API on how to access but there is no AT that
supports it.

jason - if don't use "standard" way of doing something, fail another
checkpoint.

gregg - what if create something that can only be operated with a mouse but
provide API to programmatically activate things. is this accessible even
though no AT supports it?

cynthia - AT always lags behind technology. vendor has done everything they
can do.

gregg - government must make sure workplace is accessible. if no way to
make a certain technology accessible, government shouldn't purchase it.

cynthia - to make something accessible, there are a number of things that
have to be in place - user, author, browser, AT, OS all have
responsibilities. are you saying that all software should be published in
technologies that are currently supported by assistive technologies.

gregg - government is going to buy new piece of SW that only works on XP
and 2000. government can choose not to buy it if they require it to work on
older system. customer decides.

cynthia - seems like someone could create content that meets WCAG but
someone uses it with browser that doesn't meet UAAG, then it wouldn't be
accessible.

gregg - but it would meet WCAG.

cynthia - sounded like you were saying a single vendor owned the content
and the user agent and that they had done everything to make content and UA
meet guidelines but AT doesn't yet support it.

gregg - let's go back a year or two. if an author did everything possible
to make a TIFF file accessible has nothing to do with conformance.

cynthia - scenario described included both content and rendering tool. took
a while for screen reading software to catch up with browser. w3c was
encouraging people to use newer technologies that had accessibility built
in even though the screen readers didn't support them.

gregg - if "want" to use IE and screen reader instead of HPR. HPR is
reasonably priced so it is not unreasonable to require user to use HPR. can
people choose any screen reader and any browser? no.  is there a reasonable
screen reader and browser combination that they can use? minimum should be
that 1) it is accessible using a reasonable and existing combination of AT
(not too expensive, don't have to compile yourself) 2) not something that
is unreasonable to ask authors to do.

gregg - level 1 is critical and reasonable, level 2 is important and
requires more effort, level 3 is more important things that will be
critical for some users, other category (advice) - don't know when it
applies, just want to leave it in.

jason - need someone to write proposal for 2.1

gregg - interacts with topic we just did. put hold on it until close to end
of call. see if there is a volunteer.

cynthia - like idea, wondering how it interacts with testable.

gregg - testable is a third facet.

jason - way we're doing it now - assert that you have reviewed it - can be
strengthened. review with additional "advisory" points in mind. can prove
that took them into account.

gregg - can test assertion by looking at the page

gregg - author asserts that they have reviewed the content bearing in mind
the items listed in the "factors to consider" section and that they have
done xxx or have taken those actions they felt were possible or
appropriate. that is testable. if we say they must have a process behind
it, that is not testable by looking at the page.

gregg - don't want our standards to say that effort rather than result is
good enough. only use this for things that we really can't develop
objective criteria for. companies cannot assert things easily, in many
cases not at all. an assertion like this at the minimum level is not
acceptable. liability per implied warranty law.

cynthia - minimum is what is likely to be incorporated into regulations.

gregg - may go to level 2 in some categories. if don't give them a minimum
on each one, may lose that item altogether

cynthia - they won't include anything that is not testable (like 508)

gregg - everything in level 1 has to be testable. want to hear from others
about this scheme.

gregg - conformance levels are determined by three factors 1) testability
(at least levels 1 and 2, think it has to be all three by the rules) 2)
importance - most important (both how important it is to the concept and
how it applies across the range of people affected by the checkpoint, like
to stay away from quantity affected) 3) practicality of doing it for all
content on all pages on the web

cynthia - does that include tradeoff situations such as clear and simple
text and use stuff designed for accessibility but remain compatible with
old technologies

gregg - first example doesn't exist because requirement is "as is
appropriate to the content". 2nd example - if have to create two different
web sites, not practical. on clear and simple language, level 3 could be an
alternate version like a summary or something. level 4 might be a "tuned"
site.

john - like idea. not clear on how it relates to discussion about the
conformance statement with testability in it and about minimum level not
guaranteeing "accessibility". would like to see proposal in writing.

gregg - will follow up with one.

cynthia - like general idea

andi - like idea in general but concerned that without defining minimum
requirements in terms of technology used, hard to get consensus on when
something meets the guidelines. also concerned about discussion that
minimum means it works with existing AT. several weeks ago, discussed case
of accessible Java application but no AT supports it. agreed at that
meeting that it would be accessible.

bengt - like it

gian - good idea

ben - like it. opportunity to put in more ideas than we would be able to
otherwise. emphasizes importance of checkpoints we are asking everyone to
adopt.

eugenia - like it

gregg - jason and gregg will work on 2.1 rewording. ben will help.

jason - agree with first two. problems with reasonable/practical idea -
what is reasonable to do may vary greatly depending on the technology used.
what is difficult to do today may be much easier in the future. levels
should not be distinguished based on assumptions about the resourcefulness
of the implementor or the technology the implementor has chosen to use.

gregg - reasonableness doesn't go into decisions about the checkpoints,
only about what goes into level 1, 2, or 3.

jason -  "reasonable" opens us to charge that there was compromise going on
behind the scenes in the working group.

gregg - agree that judgements need to be objective. over time it should be
easier and easier to comply with more and more.



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 Wednesday, 15 May 2002 13:33:56 UTC