7 December 1999 AU telecon


Summary of action items and resolutions


CMN PJ suggesting that the tool should do some checking. telling the author to do machine checkable checks is not good enough. we should list which WCAG are machine checkable.

PJ I thought we proposed a rewording. there are 3 categories of checking: machine checkable syntax, machine check semantic with author help, and author prompting. I think the image map example would be a good example.

JT there are some checkpoints are grey, can we all agree on that? that we can't be definitive.

PJ we could be, but things change too quickly, too hard to put tools in one bucket.

JT therefore we all agree that we can't be definitive.

PJ no, but we will live with it.

JT we define 3 types of checking. wich each type we will give examples of WCAG checkpoints.

WL only 3?

PJ let's see.

CMN i (and Ian) have been editing a proposal that discusses the 3 levels. AU 2.2 and 2.3 effectively require syntax checking. others contain partially machine checkable.

JT does syntax and semantics confuse things or add to definitions?

CMN don't think they add anything.

PJ we need to look at option B from Ian

Where it is possible to identify a problem mechanically but not directly from syntax, the tool should automate this check. For example, calculate whether two colors do not provide sufficient contrast when compared to user preferences. When the tool's calculations are best guesses (e.g., linearization of a page), prompt the user to confirm the results.

CMN I did 2 things:

  1. took "must" out.
  2. seemed like an odd separation.

JT not always machine checkable.

CMN you almost have to have by 2.2 and 2.3 some way of parsing or syntax checking

WL does this fine detail belong in guidelines or externally? it's easy to see that we could argue ad infinitum. one document should be vague, the other should be more detailed.

JT I agree.

PJ I am concerned that W3C specifications are usually specific and not left open to interpretation. The developers I have worked with want more detail. I am trying to reach a middle ground. We can make the guideline text general, then point to a specific document with more detail.

WL techniques?

PJ it's a different level of detail.

WL it has a lot of this discussion in it.

PJ but i want to know if I have to check for color contrast, yes or no. no one wants to say yes or no.

JT but no way for us to check for this automatically? If we put in those definitions of the 3 types of checking, so it is clear that you have to do something - whatever is appropriate. color is a good example.

PJ I understand. When discussing CSS, they had similar discussions. We can do this today, but aren't sure. Event model got put off to version 2. They didn't say, "CSS should support an event model." Therefore, to create something that will exist forever may not be useful if it doesn't tell them what they should or should not do. When the Federal Govnt. points to this document, we're really going to be in a bind.

CMN the question will be, is that what they're going to say.

PJ they've already said it.

JB PJ is right. some organizations will adopt this as the "hoped for" standard. for a while it will be "how close can you get." developers will have to interpret it. buyers will have to interpret. therefore, certain pieces need to be clear enough. we've had companies say it is clear enough, others have said it is not. if the WG can come no closer to clarify, then the document acknowledges which things are clear and which are not. some of the discussions have helped identify some clarity. i don't know if we can reach the level of clarity that PJ is requesting, but it is good to attempt.

JT we can document the state of the art, and be precise and definitive. however it only applies to the average tool and only be current for a short amount of time. should this be in guidelines or techniques?

JB how acceptable within guidelines document? it does not belong there. however, there may be clarification about how the document is used. secondly: i have concerns about resources and responsibility to maintain a listing of the state of the art.

WL the notion of some of these things not being resolved should be realized (e.g. alt="", alt=" ", and etc.). some of these are endless. What is or what is not machine checkable now or ever.

PJ Bill makes a valid point. we can debate these forever. I was trying to reach middle of ground.A laundry list, ala Bobby, may not be effective. I'm not ready to say that every time they use IMG they need to check for long description.

CMN the guideline doesn't say check some of WCAG, check all of them. if the best you can do is produce a laundry list then that's as good as your tool is. that's what distinguishes a good tool from a bad tool.

PJ I think i can agree with that. But it depends on how we word option C.

JT ok, so we may have a proposed compromise. expand defn of checking - the 3 classes. that will go in guidelines. also, we'll have examples. w/in techniques we will have the more definitive matrices on the responsibility of the author vs. the tool. Thus guidelines be more descriptive with step by step instruction in techniques.

PJ but we need to point to notes on SMIL, CSS, etc. that list syntactic tags from there.

CMN do that.

PJ I would put in 4.1

WL, CMN, would not.

WL objects to the proposal. it's fine the way it is.

PJ 3.1 and 3.2 need to be examined.

JT Phil, you are suggesting that we define different types of prompting, structure, etc.

PJ "many of the WCAG checkpoints are not applicable." that's the detail matrix. we need a note that when AU 3.1 says "prompt for alt info" says "those WCAG that apply to alt info." currently, it makes it sound like all 66 checkpoints. 3.2 is similar. it is only those in WCAG that refer to struct and content.

JT therefore we won't list them, but add a note to that effect. what about 5.2? nothing to do, since P1.

PJ right.

CMN techniques.

JT 1.3?

PJ started discussing yesterday.

JT ok, hold on that for a bit. what about phil's proposal. william, how do you feel. it's not an infinite list.

WL this sounds somewhat editorial. i can withdraw objections. i wouild like to see them to believe them.

CMN yes, they seem editorial.

WL therefore I vote yes.

JT objections?

/* none */

CMN to clarify a contentious point: for each WCAG checkpoint do you have to check by some means?

PJ with non-grey examples.

CMN is the understanding that you will do some sort of check for each of the 66 WCAG checkpoints. depends on wording of C.

IJ comments on CMN and my proposal?

JT we'll get to that. what we've agreed to is simple definition of the types. next need to discuss syntax and semantics.

resolved: expand defn of checking for 3 types. include non-grey examples of each. add phrase to 3.1 and 3.2 that is not all 66 WCAG checkpoints.

JT 2 floating issues:

  1. need to check for everything whether it is a laundry list or something interactive.
  2. linking in css, html notes?

PJ links to notes in the techniques doc.

JT issue re 1.3.

PJ On the call yesterday, when I said "produce WCAG content" that is has capability but does not produce all the time.

JT given that author has choice it can't always produce.

PJ 1.3 points to WCAG not to infer that tool always do that, but that can do that.

JT we give the author the ability to override everything. it can not be draconian to only produce accessible content.

GR if we say, automate syntax checks and that things that can not automatically, then why can't it automate making things accessible?

JT we all agree.

PJ this rehashes wording on 1.3.

JT where can be responsibility of the tool, it should.

PJ i think it gets into techniques and the user interface.

GR since this checkpoint has been modified. when we say, "ensure that the tool generates markup" are the transform tools included?

/* lots of agreement */

CMN does not have editing view, it creates markup when it transforms.

GR the way 1.2 is worded "ensure accessible info preserved" implies that access info is already in the format. if we're going to edit things, then 1.3 needs to be bolstered so that it has the same impression as the other sensitive checkpoints.

PJ perhaps we clarify definition of "produce."

GR yes

PJ ok

CMN i have reservations.

PJ it makes it clear that we don't expect the tool to create WCAG content w/out author help.

GR yes, but if it means more words...

CMN but it sounds trivial.

GR but what we've considered trivial the reps have asked us to clarify.

CMN some have yes. others have not. they've said, "we'll implement."

JT isn't 1.3 diff from 4.1. there are not 3 things.

PJ 1.1 says "author" 1.2 says "preservers" 1.3 says "generates" ...

JT generates = what the tool does on its own.

CMN sometimes the tool does it on its own. in those cases, there is an overlap between this and 3.1. there are things the tool can automatically do.

DB we shouldn't be mixing checkpoints in this way.

CMN effectively, to take the IMG example. in order to generate WCAG content you either need to know there is appropriate equiv stuff (checking databases, etc.) or prompt for it.

DB ok but do we need to dilute the checkpoints?

CMN what GR is suggesting is that we make it clear that the tool will automatically do what needs to be done, otherwise prompt the author.

PJ agree is obvious. but which ones are the obvious ones.

DB is the language for 1.3 confusing?

PJ no, it's determining if we meet it.

JT seem to be 3 defns.

  1. 1.3 means that the tool produces WCAG content w or w/out participation of author should be accessible.
  2. in the archives, tis is defn, when tool generates markup, should be accessible (i.e. TOOL).
  3. 1/2 way between the 2.

DB in all cases it is generating it. in some cases author helps.

GR we chose "generate" in 1.3 to cover more than just 1 instance. my problem with it is that if you look for it in the glossary you get "generated " which is a diff. ball of wax.

CMN in ordinary dictionary get the right thing.

PJ only some that i can automatically generate.

JT also alt defn, "when it auto generates."

DB bottom line is that it is producing HTML. there are times when someone is prompted to do something.

JB ways to clarify that would not damage guidelines.

IJ therefore, factor it out, put in defn. or in notes of checkpoints.

CMN put in notes in checkpoints. if we can clarify simply, doesn't damage the guidelines. what does is putting the list in the guidelines.

JB if can do that, then it is worth the groups time. it may be hard to believe that people may not understand parts. therefore take all opportunities to clarify.

GR don't want laundry list. don't want to tamper with integrity of guidelines. something in relative priority definition is an elegant solution.

CMN leaning towards clarification on checkpoint by checkpoint basis since the clarificaiton is getting mucky.

PJ in order to conform, it must conform to WCAG. which checkpoints do the tool have responsibilty for

DB the markup has to conform. in the intro we say, "auto-generate" but left out of 1.3. why not put in there. don't see the need for clarificaiton if word "automatically" is there. "ensure the markup automatically generated by the tool conforms..."

resolved: change 1.3 to read "ensure that when the tool automatically generates markup it conforms to"

JT therefore, then no need for note since clarified in checkpoint.

/* what else needs clarifying? */

PJ let's go over etc.

JT within techniques we'll link to ERT, HTML4 access draft, CSS note, SMIL note, and matrices.

CMN soon a notes for SVG and MathML.

WL point to daniel's XML access note.

JB in public space?

/* lots of agreement */

PJ where at?

GR /wai/pf/xmlgl.htm status: wai-pf draft.

JT CMN edit doc?

PJ any comment on exmaples chosen? should be more robust on A. list more not obvious one.

@@ PJ come up with more exmaples for all types.

CMN a B is abbreviation checking, basically spell checking. but want to ask author to double check.

PJ could we pick a P1 or P2 example? color is, although it is grey. i don't like color or abbreviation.

CMN but, these things become machine checkable.

PJ table linearization is a good example, for version 2 browsers.

@@ CMN check ERT for examples. WC help since not everything made it into ERT.

JT other outstanding issues?

PJ do i have to put the WCAG checkpoints into buckets?

JT we will include matrices in techniques, therefore keep working on matrices. WL any more thoughts?

WL no.

CMN proposed resolution to other issues. see the issues document.

/* no one responds */

JT believe we went through it.

CMN but PJ wasn't there.

@@PJ go through open issues list.

@@ CMN and JT additional phraes for 3.1 and 3.2

CMN is going to produce proposed text in new draft by tomorrow.

PJ the phrase "common sense dictates" should be removed.

/* right */

IJ in yesterday's UAGL, i used it.

JB but i don't like that. look into something different.

PJ after that "group has collected examples" don't refer to in guidelines. refering to section 1.3 not checkpoint 1.3. /* other comments to be sent to the list */

WL JB should use some of PJ's questions in FAQ.

JB which ones were you thinking of?

PJ let's highlight that "should scope of design may dictate which checkpoints are applicable." "Do all tools have to meet all checkpoints?"

JB even for a FAQ level we need to be more specific.

PJ conversion tool not same as site management tool.

JB others?

@@ PJ and DB send questions to Judy for the FAQ.

PJ is there a draft?

JB examples: what are diff between WCAG and ATAG? [others] some of it is for reporters.

tomorrow's agenda:

JB make sure you all read the changes carefully, especially in context.