08 Jan 2004 - WCAG WG Teleconference Minutes

IRC log

Present

Matt May, Jason White, Loretta Guarino Reid, Wendy Chisholm, Andi Snow-Weaver, Ben Caldwell, Michael Cooper, Mike Barta, Roberto Castaldo, Doyle Burnett, Bengt Farre, Dave MacDonald

Regrets

Avi Arditti, Kerstin Goldsmith, Roberto Scano, John Slatin, Maurizio Vittoria, Cynthia Shelly, Gregg Vanderheiden, Charles McCathieNevile, Geoff Deering, Yvette Hoitink

Action Items

  1. ACTION: andi propose defn of operable through a keyboard interface
  2. ACTION: jason write proposal about user agent support and author responsibility (take into consideration wendy and loretta's work from f2f after csun in march)
  3. ACTION: wendy dig up notes from loretta and wendy discussion from post-csun f2f about UAAG
  4. ACTION: ben write note that clarifies that other access methods may be available and to clarify "at least" (which is related to defn of operable, see andi's action item)
  5. ACTION: wendy propose rewrite of defn for "functionality or outcome can be expressed in words"
  6. ACTION: Mike review guidelines for consistency in how we address primary content or providing alternative (what it takes to meet the guideline. inherent that if have alternative access as part of content you satisfy, or if alternatives are called out in the guideline)
  7. ACTION: Andi forward IBM software guidelines reference.
  8. ACTION: Michael add clarification to defn of "keyboard interface" to include keyboard-style interfaces. clarify what control by keyboard interface means.
  9. ACTION: david propose rewrite defns of input device event handlers and abstract events. input device event handlers should define what an event handler is and that there are two types (abstract and device-dependent). defn of abstract build on defn of event handler.

Guideline 2.1

http://lists.w3.org/Archives/Public/w3c-wai-gl/2003OctDec/0588.html

Loretta reads proposed rewording.

http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=410

take "at least" out of parens.

it does say "all functionality>

create a note under level 1 that says, "min is keyboard but doesn't exclude other interfaces"

http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=346 - no proposed defn of operable (?)

defn of operable could help clarify the criteria. don't see prposed defn of operable.

proposed defn of operable through keyboard interface: Content is operable when it is properly designed in a way that all the information is reachable and all the funcionality is available through an efficient use of a keyboard interface. An appropriate hierarchical collection of keyboard shortcuts or a navigation bar situated after each section strengthens operability. Intensive use of tabbing weakens operability due to monotony and lack of a clear structure.

last 2 sentences are subjective.

too much tabbing makes it unusable.

action: andi propose defn of "operable through a keyboard interface"

The U.S. Access Board writes: We agree that a webpage should be navigatable by keyboard commands. However, there is always the issue of how much keyboard access is the responsibility of the webpage designer versus the capability of the specific browser being used by the person accessing the page.

If there are user agents that support the technologies you are using and that meet principle 4, and the user agents+content meet guidelines, then author should not do anything further. however, this idea needs more work.

clear that if ua does it, author doesn't have to.

isn't that "until user agents" said differently?

reminiscent of baseline discussions and mapping to UAAG 1.0 conformance profile

action: jason and wendy write proposal about user agent support and author responsibility (take into consideration wendy and loretta's work from f2f after csun in march)

action: wendy dig up notes from loretta and wendy discussion from post-csun f2f about UAAG

proposals for changing 2.1 - 1. parenthetical/note to clarify that other access methods may be available and 2. to clarify "at least"

action: ben write note that clarifies that other access methods may be available and to clarify "at least" (which is related to defn of operable, see andi's action item)

"Functionality or outcome can be expressed in words":

seems to have success criteria embeded into defn.

it has examples. hard to define w/out.

does some of this discussion belong in techniques gateway?

techniques for providing keyboard access.

techs for keyboard access are technology-specific.

analog volume control feels like in techniques gateway - it is not tech-specific.

should be enough guidance in guidelines that techs can hook into it.

possible rewording to make it a defn: Functionality that can be accomplished using buttons or command line interfaces is can be expressed in words. Continuous analong control of an interface is not able to be expressed in words.

Everything after "note:" is useful info but not a definition.

could expand on it in the techniques gateway

examples clarify defn, but "more primitive form of control..." should not be there.

action: wendy propose rewrite of defn for "functionality or outcome can be expressed in words"

trying to define "functionality or outcome can be expressed in words" but this feels like a defn of "keyboard-accessible"

how do we use this defn to distinguish between level 1 and other criteria?

level 1: exception for functionality that can not be expressed in words. level 3: no exception (thus at level 3 can not have that functionality in your content)

illustrates the diff between content that can or can not be expressed in words. thus example rather than defn.

if a function can be expressed in words, it means that there are discrete values that can be labeled (or small number of words). if a function can not be expressed in words, it is usually something that requires a gestural interaction - gestures typically require a mouse gesture.

continuous or discrete

image map: could be tabbable

mapquest map, every pixel is hot

alternate controls to them: e.g., zoom in/out, west/east, etc.

if functionality is available, then meets the requirements.

inconsistent with other guidelines where we say "or altnerative..."

need 2 success criteria in or? or put in "or equiv control provided"

if the functionality is operable, it meets the requirement.

in defn of operable, clarify that it doesn't have to be the same control or part of the interface as long as same function is performed.

talking about input, should also be concerned with output. could input info, but (in case of mapquest) what does output look like if you can't see the map. e.g., they also give directions in written form below graphic of map.

other guideline - 1.1?

if can't be expressed textually, in 1.1., then no other way of doing it.

action: Mike review guidelines for consistency in how we address primary content or providing alternative (what it takes to meet the guideline. inherent that if have alternative access as part of content you satisfy, or if alternatives are called out in the guideline)

IBM software guideline say "all functions that are not inherently mouse functions have to be operable via keyboard" then give examples of what is/is not mouse operable.

ACTION: Andi forward IBM software guidelines reference. [7]

jason willing to work on action #5 w/wendy

defn of keyboard interface

add defn of "alternate keyboard"

add to the end "as if it were being controlled by a standard keyboard"

what if the device doesn't have a keyboard or possibility of keyboard?

telephone has keypad.

addressed in example 2 (of 2.1)

if content can not be used that does have a keyboard, then doesn't conform.

does a telephone keypad count as a keyboard?

then perhaps don't need addendum

"alternate text entry methods" an umbrella statement. if some other way to get it there, that counts, too.

strike "add to the end "as if it were being controlled by a standard keyboard""

action: Michael add clarification to defn of "keyboard interface" to include keyboard-style interfaces

clarify what control by keyboard interface means.

action: Michael add clarification to defn of "keyboard interface" to include keyboard-style interfaces. clarify what control by keyboard interface means.

defn of input device event handlers

drop the last sentence (that is HTML-specific)

also defn of abstract event

could be rewritten in more general and plain language.

1st: clarify what an event handler does and that there are diff types

2nd: what abstract are capable of that device-specific are not

action: david propose rewrite defns of input device event handlers and abstract events. input device event handlers should define what an event handler is and that there are two types (abstract and device-dependent). defn of abstract build on defn of event handler.

===

wording suggestion for level 3: strike "in some fashion or degree" from end of criterion.

agreed

===

when look at keyboard interfaces, some devices are keyboard with integrated mouse interface. e.g., intellikeys that can do mouse and keyboard functions.

it is more than a keyboard interface.

or satisfies the requirement of keyboard interface

i.e., if operable via intellikeys, operable via a keyboard interface

WCAG 1.0 Errata

http://www.w3.org/2003/12/wcag10-errata-table.html

wac provides overview of errata in table. next steps: wendy has more work to do, then group should review, and we'll discuss stickier topics (primarily checkpoints with "until user agents" clauses)

michael willing to help document evidence of why to deprecate or not deprecate.

Upcoming Face-to-face meetings

techs task force 4&5 March in Cannes (part of tech plenary)

rest of group likely to meet after csun - 20/21 march in l.a.

registration and other info to follow.

to register: will need to create public w3c account to use new registration system


$Date: 2004/02/10 17:28:53 $ Wendy Chisholm