See also: IRC log
<trackbot> Date: 08 June 2012
<Loicmn> Hello everyone. I'm having troubles with my SIP connection. I may need to restart...
<shadi> survey pointer: https://www.w3.org/2002/09/wbs/55145/JUN052012/
<scribe> scribe: Andi
action-4 - due June 12th
<trackbot> Sorry, couldn't find user - 4
action-5 - Gregg reports
GV: word processing documents
would meet the input error option
... not clear so still need the modification
Survey: https://www.w3.org/2002/09/wbs/55145/JUN052012/
MP: 1.4.4 Resize Text: Bruce's suggested edit seems reasonable
no objection
<Loicmn> I'm P21
LM: agrees that techniques are out of scope
KK: concern about use of
"software renderers" - need to define
... suggest user agent
AS: user agent definition: any software that retrieves and presents Web content for users
AH: use "user agent" but explain what it means outside web context
AS: would have to keep this open until we close on the definition of "user agent"
AL: agree with approach but have to keep it open, "user agent" okay in PC world but perhaps not outside of PC world
KK: problem with "software renderer" - okay if we define what it means
<greggvanderheiden> This success criterion applies directly as written and as it is described in intent from Understanding WCAG 2.0. Electronic content and electronic documents that have software players, viewers or editors with a 200 percent zoom feature would automatically meet this SC unless the content or document has some method for defeating the zoom.
<greggvanderheiden> : This success criterion applies directly as written and as it is described in intent from Understanding WCAG 2.0. Electronic content and electronic documents that have software players, viewers or editors with a 200 percent zoom feature would automatically meet this SC unless the content or document has something that interferes with zoom.
<greggvanderheiden> This success criterion applies directly as written and as it is described in intent from Understanding WCAG 2.0. Electronic content and electronic documents that have software players, viewers or editors with a 200 percent zoom feature would automatically meet this SC unless the content or document will not work with zoom.
<greggvanderheiden> .
<greggvanderheiden> Proposal from TF meeting ========================
<greggvanderheiden> Additional guidance when applying to Electronic Documents
<greggvanderheiden> This success criterion applies directly as written and as it is described in intent from Understanding WCAG 2.0. Electronic content and electronic documents that have software players, viewers or editors with a 200 percent zoom feature would automatically meet this SC unless the content or document will not work with zoom.
<greggvanderheiden> Additional guidance when applying to Software Aspects of Products
<greggvanderheiden> ,
<greggvanderheiden> The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This would mean that either the application itself, or one of the platforms under it, would have to provide some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality and without the application interfering with it.
<greggvanderheiden> : The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This would mean that either the application itself, or one of the platforms under it, would have to provide some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality and the application must support that text enlarging capability.
<greggvanderheiden> The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This would mean that either the application itself, or one of the platforms under it, would have to provide some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality, and the application supports that capability.
<greggvanderheiden> : The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This means that either the application itself, or one of the platforms under it, would have to provide some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality, and the application supports that capability.
<greggvanderheiden> The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This means that either the application itself, or one of the platforms under it, provides some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality, and the application supports that capability.
RESOLUTION: accept 1.4.4 text for documents as amended in the meeting
<greggvanderheiden> : The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This means that either the application itself, or one of the platforms under it, provides some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality. If the platform is relied upon, the application supports that capability.
<greggvanderheiden> The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This means that either the application itself, or one of the platforms under it, provides some means for enlarging the text 200% (zoom or otherwise) while retaining full functionality. If the platform is relied upon, the application supports the platform capability.
<greggvanderheiden> The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This means that either the application itself, or one of the platforms under it, provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality. If the platform capability is relied upon, the application supports the platform capability.
<greggvanderheiden> The INTENT refers to the ability to allow users to enlarge the text on screen at least up to 200 % without needing to use Assistive technologies. This means that either the application itself, or one of the platforms under it, provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality. If a platform capability is relied upon, the application supports the platform capability.
RESOLUTION: accept 1.4.4 text for software as amended in the meeting
2.1.1 Keyboard Operation
<janina> +1 to Andi
AS: either need a more device independent term than "keyboard interface" or we need to define "keyboard interface" to be more generic than keystroke encoding
AL: game controller input depends
on the path so it qualifies for the exception
... is this only about a device that can accept discrete
input?
<greggvanderheiden> re AL: the exception is only for input that can ONLY be done via ….etc.
DM: WCAG is still in the keyboard world
KK: can't use keystroke encoding - lots of input mechanisms - the key is a device independent way
AH: have to live with what is in WCAG. Could add note that many other ways are coming that need to be looked at.
GV: have to go with what's
here
... dpad is time dependent which violates another success
criteria
... can be any kind of device that generates discrete commands
that are not time dependent
... allows speech, Braille, etc. input
AL: dpad is similar to using arrow keys where you hold down the arrow key to scroll the page
GV: simple taps on the dpad work but holding it down doesn't work because it's time dependent just as holding down an arrow key doesn't work because it's time dependent
AL: buttons on game controller are the same as buttons on a keyboard
LM: points out that 2.1.1 does say "without requiring specific timings for individual keystrokes"
<greggvanderheiden> Additional guidance when applying to Software Aspects of Products
<greggvanderheiden> Keyboard interfaces are programmatic services provided by platforms that allow text input and operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard, but only the existence of a means to input text and control the software using encoded (keystroke) input. This encoded (keyboard) input could come from a virtual keyboard or from a physical built-in or external (wired or wireless)
<greggvanderheiden> keyboard. Nothing in the WCAG INTENT discourages pointing, gesture or other input as secondary or primary mode of input as long as the SC is met.
KK: what about T9 keyboards?
GV: T9 keyboards generate
keystroke input
... swipe requires timing but the function being invoked by the
swipe does not require timing
AS: propose removing "(keystroke)" from "encoded (keystroke) input"
GV: would have to define "encoded input" which would make it harder to read - mouse input is "encoded input"
<Loicmn> This encoded (keyboard) input could come from software (such as a virtual keyboard or a speech recognition engine) or from a physical built-in or external (wired or wireless) keyboard.
JS: too much focus on the device that is generating the event, even keystroke generates scan code
AH: change keyboard to character
<Loicmn> It's not only character (think about arrow keys and "tab")
GV: arrow keys are not characters and they are allowed
DM: what we were trying to do for WCAG was a very narrow focus
<greggvanderheiden> This encoded (keyboard) input could come from software (such as a virtual keyboard or a speech recognition engine) or from a physical built-in or external (wired or wireless) keyboard or any other method for generating character plus control key input.
GV: Andi wanted to suggest an edit to the last sentence that would clarify this is not an exhaustive list
<greggvanderheiden> interface used by software to obtain keystroke input
AS: should use one term unless we really mean something different by "encoded (keyboard) input" or "encoded (keystroke) input"
<Loicmn> What we really need is a non-timing way of providing text + control input. Forget about the "old ways" (key codes).
<greggvanderheiden> This keyboard (encoded) input could come from software (such as a virtual keyboard or a speech recognition engine) or from a physical built-in or external (wired or wireless) keyboard or any other method for generating keyboard (encoded) input .
AS: also concern that if we persist in requiring this to be keyboard or keystroke input, no mobile software will be able to comply no matter what they do to solve the problem.
AL: mentions other forms of input such as a camera
GV: camera input can't be used to
operate functionality
... 2.1.1 is only about the way you operate the
functionality
... hard to imagine any kind of mobile device that doesn't
support character input
... if can only operate with gestures, it won't be
accessible
MP: need more proposals - suggests continuing debate via e-mail
DM: fundamental question we need to resolve amongst ourselves
GV: solution might lie in Andi's idea of "device independent" - can she provide a description of how that would work
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/action 4/action-4/ Succeeded: s/text for documents/1.4.4 text for documents/ Succeeded: s/text for software/1.4.4 text for software/ Succeeded: s/Bruce's suggested edit seems reasonable/1.4.4 Resize Text: Bruce's suggested edit seems reasonable/ Succeeded: s/andi was encoded the only edit you wanted to make?// Found Scribe: Andi Inferring ScribeNick: Andi Default Present: Kiran_Kaja, Al_Hoffman, Andi_Snow_Weaver, Mary_Jo_Mueller, Suzette, Shadi, +1.425.822.aaaa, Janina, Judy, Loïc_Martínez Present: Kiran_Kaja Al_Hoffman Andi_Snow_Weaver Mary_Jo_Mueller Suzette Shadi +1.425.822.aaaa Janina Judy Loïc_Martínez Regrets: Bruce_Bailey Agenda: http://lists.w3.org/Archives/Public/public-wcag2ict-tf/2012Jun/0015.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/08-wcag2ict-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]