phone: Wendy Chisholm, Ben Caldwell, Gregg Vanderheiden, Roberto Scano, Loretta Guarino Reid, Eugenia Slaydon, Jason White, Doyle Burnett, Bengt Farre, Andi Snow-Weaver, Eric Velleman, Avi Arditti, Lee Roberts
IRC: caldwell, Zakim, bengt, wendy, rellero, rscano
Maurizio Vittoria, Cynthia Shelly, John Slatin
Refer to Wendy's responses to comments
summary of proposals and contentions: proposals #1 and 4 were not contentious. 2, 3, 5 are.
use of term device independence: some feel it is well enough understood to use it. however, others feel there are issues with device indie.
there is strong feelings by some that we *do* want to require character input. character input doesn't mean to use a keyboard... could be also voice command
proposal: ensure that it is operable at a minimum via the keyboard or keyboard equivalent
decided not to include a parenthetical phrase or example in checkpoint or success criterion text.
issue: add user requirements to success criteria to help clarify? NO. increases the length too much and we are very sensitive to keeping this as succinct as possible
issue: is character input more accurate than "keyboard or keyboard equivalent?" for voice apps is that if can't speak, need to use keyboard.
proposal: unicode stream
issue: no one will know what that means.
proposal: DTMF (phone key press) is not enough
if can send character input, it should be picked up by user agent or content, then satisfied.
proposal: keyboard or other character input device
proposal: ought to link to "assistive technology" section of "how people w/disabilities use the web"
resolution: checkpoint text: Ensure that all of the functionality is operable, at a minimum, through the keyboard or other character input device. word success criterion accordingly (will say basically the same thing but in success criterion language)
proposal: word "content" applies to web pages and applications.
resolution: ensure that our use of the word content is consistent with other guidelines.
action editors: take use of word content to xtech (for glossary discussion)
resolution: delete level 2 criterion.
resolution: make addition to benefits ala wendy's proposal (ala interpretation of comments from aaron and WWAAC folks)
published new draft this morning that includes proposed resolutions to issues raised by chairs and on the list.
proposal: let the group look at for a week and if no issues, publish to TR next week.
counter-proposal: discuss at next week's call.
proposal: replace "human testable" is "reliably human testable"
issue: "untestable" is not right... there could not be not testable
proposal: reliably human testable and not reliably testable
otherwise, if a checkpoint is untestable, how can check it?
proposal: replace "human evaluators" with "informed (or knowledgable) human evaluators
resolution: replace "human testable" with "reliably human testable"
resolution: replace "untestable" with "not reliably testable"
resolution: replace "human evaluators" with "knowledgeable human evaluators"
resolution: incorporate these resolutions, publish back to list, check in with folks at next thursday's meeting, if ok, then move forward.
V2 on 17/18 March (monday/tuesday of CSUN) and EITTAC is undetermined.
sunday/monday after csun are free and sat/sun before are free, thus: either weekend before (15/16) or sun/mon after (23/24). another possibility is the sunday before and sunday after. perhaps sunday before - guidelines, sunday after - techniques?
action wendy: send set of proposals to the list for different votes and ask people to vote.
avi still drafting text of success criterion.
proposal: not have anything in guidelines that addresses question of new and old content. instead we include discussion of conformance describing proper ways to claim conformance for material that is new and revised as of a date. Also proper use of WCAG 2.0 conformance logo.
issue: proper way - already established?
not yet.
lisa proposed on the list that if already conform to wcag 1.0, then that's ok don't need to retrofit for 2.0:
this gets back to policy and some people are not comfortable with that
some feel that it should be like conformance to html - you deprecate older versions but you don't outlaw using older versions
they could stay with WCAG 1.0 if they use old version of HTML. But if they use XHTML with CSS 2.0 or greater they must apply WCAG 2.0 or greater
i think that we need to put it as a fundamental point: "WCAG 2.0 must be applied from web developers that develop web sites and web content that are covered by the checkpoint of these guidelines that comes in substitution of WCAG 1.0."
some people feel that with new technologies, easier to interpret 2.0 than 1.0 to meet their needs.
should not add burden by making them redo all work to comply with 2.0 instead let keep 1.0 but add something like an End Of Life statement when this has to move forward in technology ?
i think also that we need to make a section like diffs between XHTML and HTML 4.01 (in the XHTML 1 spec)
action gregg: draft resolution (related to proposal about conforming to 1.0 vs 2.0) so that can be reflected in the conformance section of the guidelines (ways of reporting and use of logo). deadline: 3 weeks from now
proposal: in core techniques - section related to conformance claims.
http://www.w3.org/TR/WCAG10/#Conformance
proposal: look at uaag conformance chapter
some feel that it is too long and not what we are after.
action jason: draft something after gregg finishes submits his proposal (about making conformance claims).
$Date: 2003/01/17 03:08:02 $ Wendy Chisholm