08 February 2001 WCAG WG telecon minutes

Minutes available in HTML at: http://www.w3.org/WAI/GL/2001/02/08-minutes.html

08 February 2001 WCAG WG telecon minutes
Summary of action items and resolutions
·       Resolved: Accept Jason's edits to the WCAG 2.0 Techniques draft.
·       Resolved: Editors (per sean's list) should begin writing techniques 
using the latest draft as a model.
·       Action MM: work on a quality control testing procedure for techniques.
·       Scribe note: refer to "template for making techniques" submitted to 
the list by lisa seeman 5 January 2001.

Participants
Katie, Wendy, Jason, Marti, Annuska, Matt, William, Loretta

Regrets
Cynthia, Gregory, Rob, Gregg, Dick

Techniques for WCAG 2.0

Background
Technology-specific checkpoints - updated 6 February 2001.
Jason's suggestions published 7 February 2001:
Merge XHTML into the HTML requirement list (only treat it separately where 
issues of modularization are relevant).
Checkpoint 1.1 does not, in my opinion, apply to CSS. To what extent should 
CSS be treated separately from HTML/XML?
We should think of a better term than "technology-specific checkpoint", not 
only is this a cumbersome term but it invites confusion with the 
checkpoints in the guidelines. I would propose instead to call them 
"techniques", defined as follows: A technique is a concise statement of an 
implementation strategy which satisfies one or more checkpoints. Often, 
techniques are specific to a given web-related technology. In the actual 
document, techniques would be sharply distinguished from the following: a. 
Code examples. b. Discussion. The existing structure of the Techniques 
document would be maintained--that is, there would continue to exist a set 
of core techniques, together with technology-specific techniques for 
(X)HTML, CSS, SVG, SMIL, client-side programming (i.e. scripts), etc.

Discussion
WC Appropriate wording? Examples in a separate file.
JW Call it techniques rather than technology-specific checkpoints.
WC This be techniques and sub would be examples. Imagine a separate page 
for technique, has examples, screen shots, etc.
JW Yes.
MM How cross-referenced with other technologies? What about scripts?
JW A different document for each technology?
MM Link back.
WL A database with everything. Press javascript and get everything.
JW Published as a document, each technology has its own document.
KHS Techniques for HTML, Techniques for CSS, etc.
JW If everyone agreed, then we can begin drafting them. When we come to 
conformance requirements we can determine if they have a role in 
conformance scheme.
KHS Calling techniques is good. Separate page is good.
JW A core that goes across technologies, like 1.0.
KHS In general think people will go to specific ones.
WC Those of you who had volunteerd to work on this, thoughts?
LGR This was the direction we were headed already.
JW Any issues regarding modularization should be separate, but the standard 
usage issues should be combined.
Resolved: Accept Jason's edits to the WCAG 2.0 Techniques draft.
Scribe note: refer to "template for making techniques" submitted to the 
list by lisa seeman 5 January 2001.
Resolved: Editors (per sean's list) should begin writing techniques using 
the latest draft
as a model.

Until user agents
MM What are the technologies we are worried about?
JW Would you propose that checkpoints that have a choice state it more 
explicitly?
MM Start with the features we are concerned about and see how to relate 
those to checkpoints. 2.2 says "user agents may offer control of..." Most 
do not that clearly relate a checkpoint to a specific technology.
JW It is theoretically possible that a UA offer control of it in one case 
and not another. e.g. SVG vs. other graphics formats. Provides control over 
for one and not another. That's the type of complexity that we need to 
consider.
MM Perhaps then start with the end-user affect we're looking for. Perhaps 
it's a technique. Qualifying the user agent
WC What about WML?
JW Superceded by XHTML Basic. Therefore which modules to use.
WC Thinking a lot lately about screen readers and their interaction with 
browsers. Where they break the access to the web by overriding browser 
support of features. Like jaws not allowing IE to link to id's.
AP - convey user experience based on which technology they are using. How 
does it impact a user. e.g. space for alt-text - what is the impact for the 
user. I tried out Jaws and WindowEyes, this is the information we need to 
include as we move along. So, here is the technique and here is the affect 
of the user.
MM Then we end up with a long list.
JW There are differences between Europe, America, ...
WC We don't have to show them every example, but some better than none.
JW Certainly.
WC I would love to see a production line. Say Matt writes a technique then 
passes it to Annuska who checks it out with Jaws, then to someone else to 
test with browser X, then browser Y, etc.
MM Yes. Quality Control. I have Jaws 3.5 and PWWebspeak
JW EmacSpeak
KHS Jaws 3.7
AP Jaws and WindowEyes
KHS Think of it as a matrix.
WC Also other software - scanning, reading software for reading 
disabilities, etc.
JW Also screen readers that work with braille displays.
KHS We'll have to have a baseline that everyone will work towards. Do most 
people use X? Should we make it work with X since most people use.
WC MM do you know about Quality Control?
MM Yes.
WC Could you help write a testing procedure for techniques? The procedure 
that we use to determine if something is accessible would then be included 
for others to use.
Action MM: work on a quality control testing procedure for techniques.
WC Perhaps work with ERT to develop tools to help us evaluate.
KHS Brookstalk being given with IE6.

$Date: 2001/02/08 22:29:46 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--