WCAG WG weekly telecon

TTF update

mc: requirements for general techniques and test files
... talked about applicability conditions - addition to a technique. adding a piece of metadata that indicates when a tech is applicable.
... important piece for checklists. agreed to add applicability conditions to the techniques.
... finished yesterday talking about test files.
... we've been discussiong how to speed up that process.
... we're assigning batches of test files to people to review.
... trying to identify landmines
... those that don't have issues, think we might get through review process more quickly.
... believe we will put forth the entire suite of test files, but clearly indicate which are accepted or not.

gv: the way to do that would be to have 2 documents rather than one with flags.
... people will be most interested in the tests that they have to live with.

wac: propose that we have ednotes at top of each test case.

gv: why would we put up something that we hadn't agreed on?
... there have been places where we weren't sure how to move forward with something, where we used ednotes. we've never published something publicly that has been submitted to us but has not been cooked.
... if it's, "we need to get something out..." then we ought to do something. what is served by putting out tests that we never have any intention of using.

wac: we are doing a review of the tests before we publish them. some of them may or may not have consensus on them. it is a "hives" review. looking for contentious issues.

gv: the way michael described it sounded like "sorting"

cr: all of the tests are based upon techniques. they are already published as techniques. they have already seen them.
... if you say, don't publish tests until accepted, do we remove the associated techniques as well?

gv: we have always had techniques that are not required.
... the techs were never viewed as things you had to do. tests, however, are different.
... tests will either be independent of the checklists...
... useful to have tests for whether something is done or not. checklist is then what people are interested in.
... the checklist is what people are waiting to see, they aren't itnerested in the tests.
... they want to know what you have to do for each SC.
... didn't think we'd have complete pieces this time around, but a complete set so that people can see what they look like.
... are we going to have tests for things that are not on the checklist?

mc: a further reason to publish the tests that are not fully discussed is to help demonstrate the scope of the project.
... there are a lot of test files and that in itself is worth people having to see.
... some of the tests that have not been fully reviewed, there are reasons they have been proposed. but erasons that they may also be contentious.
... it is worth getting outside input.
... not saying that we absolutely must go ahead that way, but think there are many good reasons to do so, although also hear reasons not to.

gv: u said, useful for people to see how many tests there are.
... to show ppl we have a lot of work to do?

mc: someone who is going to imp the guidelines, will either imp an eval tool that utilizes those tests or a checklist.
... that level of detail has to exist...useful to see how much detail there is

gv: what if there are 200 tests but only 50 have to be complied with.
... would people worry about the bulk of them if in fact there won't be that many.
... we would generate a lot of comments - ppl saying, "you can't require tihs."
... fear we would generate a lot of heat and not much light.
... then, we'd have to go through each of those bugs.
... fear that would slow us down

cr: i'm concerned about the slowness, too. so far we've accepted 10 and rejected 2.
... feel that we are likely to have higher acceptance rates and less rejections.
... good to get them out there and for people to comment. better to get comments sooner than later. good for people to see what coming.

gv: i've seen more than 2 that have no basis in the guidelines.
... we need to be careful that the guidelines require you to do things but not that you have to do them well.

gv: 200 isn't that many. get through in one 2 or 3 hour call?
... some of the tests would be either level 3 or level 4
... there are ways to do level 1 stuff better.
... we don't require it, but if you want to do level 1 really well...therefore that would be level3-like.
... until we have a place to require them, they can't be WCAG 2.0 tests. they could be WCAG 2.0 advisories, but that's not the way people will read them if we say they are WCAG 2.0 tests.
... perhaps when you do the review, ask people to pick out those that are definitely required by WCAG 2.0 and the SC that require them.
... let's see if we can't sort tests by their opnions...
... could avoid discussing wording, focus on if they are required, good but not required, trying to decide if required or not.
... that could cut down on the comments that we get.
... we need to reserve the public comments for those things that we have cleaned up and feel confident about.
... look at the number of bugs we have on the guidelines that we think are getting stable.

jw: suggest that everyone should take the list of test cases and raise any of those that are objected to before publicaiton. it's just a matter of everyone reading through them and listing those that they object to.
... improving is one thing, objecting to is another thing.

gv: required, don't think required, don't know, needs wordsmithing - could do a poll that way
... how long would it take someone to read through the 200 tests?

bc: better part of a day - have to read techniques, guidelines, etc.

mc: would like to move forward with the proposal to break up into groups for ppl to review

cr: about the straw polls - you can say which level, if want to be optional or kill. that seemed to be confusing. think a simpler poll is easier: accept or reject.
... before the poll, we discuss so taht people understand the tests.
... not sure how valuable to have a general poll until we have some discussion.

gv: thought using the poll to determine which ones to discuss?

bc: this is a bit cart before the horse. started out polling on techniques.
... perhaps first classify techniques and then classify the tests.
... looking at the tests for techniques completeness.
... think the polling should be on status of techniques.

gv: thought our goal this time around was to get enough of the pieces to show how they fit together.

http://www.w3.org/WAI/intro/wcag20

dmd: up to this point, assumed we would not have techniques that we could not map back to a guideline.

gv: there is a difference between map back to and specifically required by.
... is my description way off from where people think we are headed? or alternate map to move forward?

cr: think it should be like wcag 1.0: must, should, may
... 3 was iffy, or burden or.. level 3 was there as resource.
... as it is now, virtually no site conforms to AAA

(WCAG 1.0 AAA)

cr: i thik people will think of WCAG 2.0 in the same way.
... doubt people will go for level 3.
... if level 3 is really attainable and then have something else (level 4 or best practices), then that needs to be realy clear.

gv: some people feel that you could have level 3 conformance w/out doing all of...perhaps some %. others disagree.
... we didn't argue that one out, b/c we wanted to finish level 3 first.
... weren't sure what was in level 3, therefore not sure what arguing.
... most people seem to feel that most sites will not meet level 3
... the reason for level 4, there are some things which are not testable
... folks from industry are worried that someone somewhere will require level 3. therefore, don't want stuff in level 3 that is good advice.

<Yvette_Hoitink> gv: My understanding that we have a "level 4" in techniques documents with good advise

<Yvette_Hoitink> gv: is that the general understanding?

<Yvette_Hoitink> gv: anyone who doesn't think that's a good idea?

<Yvette_Hoitink> someone: I thought techniques would be for SC and would map back to a guideline

<Yvette_Hoitink> gv: map back to is different than required for

<Yvette_Hoitink> gv: we used to require testing with people with disabilities

<Yvette_Hoitink> gv: still a good idea but not required

<David> kerten: concerns - people will take take techs and make them the final word

<David> kerstin: prefers them in a completely separate space, if it is not tesable and best practise its level 3 confusing for legislation

<David> kerstin:correctin of above- said if it was testable & best practise put in level 3 if not testable drop it...

<David> gv: have test procedures separate from techniques. tests like legal system...techniques like churches and synogoges...

<David> gv: would like to see if we have done 2 things...1) do we have and architechture for the relationship betweenn tests, techniques and guidelines?

<David> chris: techniues to author...afterward use test and checklists......

<David> gv: legalistic approach can just follow tests...but a really accessible site will go from techniques

<David> gv: don't want to have test procedures around that are unrequired but don't want to throw them out either.

<David> kerstin: are ther 2-3 tests for each SC

<David> gv: should be 1-1 relationships checklist to sc

<David> correction1-1 checkist to test procedure unless if they are or, may have several checklists for each sc

<David> gv: each checklist item would have one test...1-1 relationship

<David> unless their are "or's"

<David> andi: critical point where we need to generate checklists...

<David> gv: yeah pushing toward it

<David> bc: we met this mornins hope to have prototype for 1.1 for next week

<David> gv: can't have specific technology checklist ...should be one big checklist document, that would be filtered...according to conditions

<David> gv: ie if you have not pictures it would filter them out....people would select the technologies they want

<David> gv: michael do you have a good idea for a plan for "we agree...on theste tests