IRC log of wai-wcag on 2004-01-15

Timestamps are in UTC.

21:12:21 [RRSAgent]
RRSAgent has joined #wai-wcag
21:13:04 [Yvette]
Wendy: refine the note with the checkpoint but don't depricate the checkpoint, delete the phrase 'until user agents...'
21:13:24 [MichaelC]
ack Wendy
21:13:43 [Zakim]
21:14:19 [rellero]
rellero has joined #wai-wcag
21:14:30 [ben]
ack Andi
21:14:37 [ben]
ack IBM
21:14:45 [rscano]
ack [IBM]
21:14:47 [Yvette]
Andy: deleting 'until user agent' removes the rational behind the checkpoint
21:14:57 [Yvette]
this changes the guideline
21:15:34 [Yvette]
If 'until user agent' is dropped, is it still priority 2? Or can it be dropped down to 3?
21:15:44 [Zakim]
21:15:48 [Zakim]
21:15:48 [rellero]
zakim, I am Roberto_Ellero
21:15:49 [Zakim]
sorry, rellero, I do not see a party named 'Roberto_Ellero'
21:15:56 [Yvette]
John - Makes great difference to people using screen magnifiers, so should remain priority 2
21:16:14 [rellero]
zakim, I am rellero
21:16:14 [Zakim]
sorry, rellero, I do not see a party named 'rellero'
21:16:36 [Yvette]
Not known if screen magnifiers support explicit association of labels
21:16:44 [Yvette]
Wendy can do more research
21:17:41 [Yvette]
Some screen magnifiers have their own browsers, unknown if they support label tag
21:18:50 [Yvette]
How many user agents have to support something before we deprecate 'until user agents clauses'?
21:20:13 [Yvette]
Wendy - Adaptations to WCAG 1 should be in spirit with the original intent
21:21:04 [Yvette]
If magnifyers don't adequately support label, the 'until user agent' should stay.
21:21:28 [Yvette]
What would label support look like in screen magnifyer?
21:21:49 [Yvette]
Normally, magnifyers only deal with visual display of the page, not underlying structure
21:21:52 [rellero]
rellero has joined #wai-wcag
21:22:32 [Zakim]
21:22:32 [Yvette]
Good lay-out can help (vertical stacking of controls, etc)
21:22:36 [Zakim]
21:22:52 [Yvette]
Users using a mag tend to miss stuff on the right
21:22:56 [rellero]
Sorry, I can follow only in irc
21:23:01 [Zakim]
21:24:14 [Yvette]
How would labels help for magnifyers? Several possibilities from reformatting the form to Perhaps reformat the form to additional help on form elements
21:25:15 [Yvette]
What's the label-support in text browsers?
21:27:25 [Yvette]
WE're going for Wendy's first proposal
21:27:40 [Zakim]
21:27:49 [Yvette]
The checkpoint stays, the note will be clarified
21:28:06 [Yvette]
It stays level 2
21:29:53 [Yvette]
New topic: Guideline 2.1 of WCAG 2
21:30:06 [Yvette]
includes discussion about definition for 'keyboard interface'
21:31:14 [Yvette]
Michael's version + edits was well received
21:34:16 [rscano]
and use: keyboard or keyboard equivalent?
21:34:37 [Yvette]
Michael + 2:On devices that do not have a built-in or attached keyboards, there is usually an alternate method for connecting a keyboard to the device for the purpose of entering text.
21:34:37 [Yvette]
Allowing control via the "keyboard interface" means that the content could be controlled through commands issued from the keyboard or by alternate entry methods that are capable of generating text as if a keyboard had been used.
21:35:03 [Yvette]
Add "internal or external" in the second sentence?
21:35:18 [Yvette]
... alternate internal or external entry methods...
21:36:06 [Yvette]
Can add third sentence
21:37:56 [Yvette]
Word 'text' is bit difficult, other variants 'keystrokes', 'commands' have their own problems
21:39:00 [Yvette]
'entering text' is too narrow, it's also for operating the device
21:39:09 [Yvette]
but text is used for operation as well
21:39:33 [Yvette]
First sentence should read '... purpose of generating text' (use generating instead of entering)
21:41:47 [Yvette]
Some shops have internet computers without keyboards to 'trap' you on their own website
21:42:30 [Yvette]
sentence 1 + 'or an internal method for generating text'
21:43:34 [Yvette]
sentence 2 "alternate methods' instead of 'alternate entry methods'
21:44:10 [rscano]
"for enter data" i think is best that "insert text"
21:46:25 [Yvette]
used to be "requires character input", perhaps that was not so bad
21:46:35 [Yvette]
Word 'text' is ambiguous
21:46:37 [rscano]
21:47:42 [rscano]
dfn for keyboard:
21:47:54 [Yvette]
What was the purpose of this checkpoint?
21:48:17 [Yvette]
Some aspects are covered by other checkpoints
21:48:45 [Yvette]
Andy can't think of anything you can do that isn't covered by 4.2
21:49:15 [Yvette]
Counter-example: mouse-over only isn't keyboard friendly
21:49:53 [Yvette]
4.2 has to do with robustness, not operability
21:50:10 [Yvette]
Does 4.2 really belong under operability instead of robustness?
21:50:23 [Yvette]
Perhaps combined with 2.1?
21:50:53 [Yvette]
Mouseovers etc. are programmatic interfaces
21:51:29 [Yvette]
:hover isn't
21:52:29 [Yvette]
4.2 is about custom interface elements and display, so can't be combined with 2.1
21:55:12 [Yvette]
Be careful to keep success criteria out of the definitions
21:56:02 [Yvette]
efficiency by keyboard is another layer: perhaps we can attach a note to checkpoint 2.1
21:57:44 [Yvette]
Definition of event handler (just posted on mailinglist) sounds good
21:58:33 [Yvette]
Text for guideline 2.1 itself is being rewritten
21:58:57 [Yvette]
Andy is working on definitions
21:59:29 [Yvette]
Event handler: A section of code that responds to an action taken by the user (or user agent). On web pages, events are usually user actions such as moving the mouse, typing, etc. An event handler determines the response to that action. A technology specific event handler only responds to an action by one kind of input device. An abstract an event handler is one which can be activated by a variety of input devices.
22:00:16 [Yvette]
Defition for "functions or outcomes that can be expressed in words"
22:00:51 [Yvette]
22:02:50 [Yvette]
Definition itself cannot be expressed in words, apparently
22:04:08 [Yvette]
Difficult to express sensory experience in words
22:07:04 [Yvette]
Goal: To not require keyboard access for for example watercolor application
22:08:29 [Yvette]
Some things are just not possible to be done from keyboard
22:08:29 [Zakim]
22:09:46 [Yvette]
Does functionality can be expressed into words necessary for keyboard control?
22:09:58 [Yvette]
22:10:15 [Yvette]
If you can't describe the function into words, you cannot operate it from a keyboard
22:12:10 [Yvette]
For example: try to describe how to hold a brush to make 1 brushstroke
22:12:43 [Yvette]
"Concise" was supposed to be included in the definition but isn't there
22:13:36 [Yvette]
use "labelling it" instead of "express in words"? No, 'Label' is confusing since part of HTML
22:16:40 [Yvette]
Perhaps change to "expressed in a sentence" to make sure no 25 p. novels appear
22:16:52 [Yvette]
Get's rid of 'concise' as well
22:21:05 [Yvette]
2.1 Level 1 Success criteria: "If the action or the outcome can be expressed in a sentence it should be operable from a keyboard or keyboard interface."
22:21:43 [Yvette]
Readers will think "What does expression in sentence have to do with keyboard interface?"
22:22:28 [Yvette]
Correction: "all of the functionality of the content, where the functionality or its outcome can be expressed in a sentence, is operable at a minimum through a keyboard or keyboard interface. "
22:23:13 [Yvette]
Don't want to suggest authors should build natural language interfaces
22:23:28 [Yvette]
perhaps 'described in a sentence'
22:31:27 [Yvette]
drop 'at a minimum', + "Other interfaces such as a mouse can be provided in addition."
22:33:04 [Yvette]
New 2.1 formulation: all of the functionality of the content, where the functionality or its outcome can be described in a sentence, is operable through a keyboard or keyboard interface.
22:33:23 [Yvette]
New explanatory note: Other interfaces such as a mouse can be provided in addition.
22:36:12 [Zakim]
22:36:13 [ben]
RRSAgent, bye
22:36:13 [RRSAgent]
I see no action items
22:36:14 [Zakim]