WAI Authoring Tool Guidelines Working Group
Chair: Charles McCathieNevile
Date: Wednesday 6 December 1999
Time: 3.00pm - 5:00pm Boston time (1800Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the working draft dated 2 December, available at http://www.w3.org/WAI/AU/PR-WAI-AUTOOLS-19991202.
CMN The rest of the issues other than the matrix are proposed as settled. Have people read the new draft, which has language that is the proposed resolution for the other issues.
IJ Haven't read it yet - will do so tomorrow
/* Phill Joins
/* Jutta joins to send regrets
PJ Is the skill level discussion in the draft?
CMN Yes
PJ I didn't think it was resolved
CMN Please have a look and let us know if we aren't more or less there
Action CMN: Link issues list today.
PJ So do we ask for an explicit vote from members, or do we look for implicit agreement?
JB If people are not on the calls then Charles should talk to them.
PJ I realised after sending the table that the source of the checklist was the march 24 version, not the May 5 Recommendation version. There are some quirks in there as a result. I will update the table. The other thing is that the table markup doesn't have header markup and so forth.
GR Can you linearise the table please?
PJ when I put up several checkpoints in concert you can see that some are tool and some are not.
CMN I can drop it into tablin and make a linearised version.
PJ I haven't gone through CMN's totally, but I was working through it. GR said we shouldn' tell them how to check when we have told them what to check for. My response was that we haven't told them what to check for, just set them to WCAG. I was trying to tell them what were author checking - what is not the responsibility of the tool. In some cases there may exist a technique but it may not be reasonable to ask a tool to implement it. THere is the question of the type of tool and whether it has to implement something. An example is the site map requirement. Clearly we wouldn't require all tools to make a site map, although we would require some of them to do so. There are checkpoints that relate to the scope of the tool, but that is the only one I found so far. The overall impression I had when filling this out was that I thought we could reach agreement on what the minimum requirement is for tools. If we can't articulte the minimum requirement I don't think we have done the job.
CMN We can be as global as suport them all, and the minimum kind of support is to guide the author. That would lead to a tool that is really annoying to use, so there is a responsibility in the techniques document to provide guideance about how to do better than that.
PJ You'e saying on every WCAG checkpoit the tool needs to include some kind of approach. Do I need something different for each checkpoint?
CMN Not necessarily.
PJ We have differing interpretations - two groups of developers looked at it diffreently, one being pessimistic and one being optmistic. One group went to the techniques document, and said We don' impleement any of the techniques, so we are not compliant.
JB Then they didn't read it properly
IJ That should be in the FAQ
PJ The other group looked at the techniques as examples, and had refrenced WCAG and argued that was providing context-sensitive help.
JB It sounds as though the issue of somebody misunderstanding the techniques document is somewthing we could reinforce in references and the tech document, and after that I would say a company is on their own - they have a bigger communication problem than that.
PJ We got past that to say the techniques are not all required, and looked at which techniques they had to do
JB The clarification should be that the techniques are illustrative, and for the checkpoints they have to do everything
PJ There is no way to do abbreviation checking in a real tool
GR There is a possibilty to do that
PJ But it was a huge job for a P3. So for WCAG 1.1, what are the tages used to specify alternative content? We need a definmitive list
GR That comes free in HTML out of a validator. Some of the basic requitrements are just validation.
CMN So what about other languages? This is a question of what the scope of the guidelines are - if we have to do it for HTML we would have to do it for everything
PJ Thre are some notes we can point to for HTML, CSS, SMIL. The tool has to ensure some level of checking for WCAG 1.1. But when you get to 2.1 there is no automatic checking in every tool. It might be possible to guess.
GR I don' know how to do it for every tool either. But you can flag it often. If I am an author and put black on black I would like the tool to check it for me.
DB Liking it, and saying it must be done are different things - do we require it?
PJ Right now it is a P1 and I think that is an undue requirement
DB It comes down to meaning of ensure
GR Right. When I use CSS validator it picks up stuff like that
PJ Do you think that is a P1?
GR Yes. I have been trying to bank online, and it is colour coded
DB Does bobby catch that?
GR I think it is under the manual checking in Bobby.
PJ Looking for existing checking. We notice you used colour, did you do it right?
JB That seems adequate
DB You would have to tell them what the problem is.
PJ I think Bobby would have dealt with it if it could be done
DB There is a question of when you do this
PJ That's technique
DB I think it is a sticky area of how far we have to go for compliance
GR To me, when the colour change will be an issue iswhen you use PDFtoHTML - they have a rpoblem in analysing. I'm trying to think of ways to the WCAG checks to regular validation checks, because you get easy wins.
CMN I think that saying you used colour did you do it properly, and pointing to the help, then you satisfy the AU checkpoint
PJ That doesn' meet the WCAG need necessarily. I don't want to say "you can satisfy this by asking the author"
GR The danger of having a matrix is that you are setting up a low target
CMN I don't think a tool that ignores the question is good enough
PJ If we prompt authors all the time then people will throw away the results.
JB I second that
PJ We don' want all this fluff - it is not real value.
GR I agree that there is a tendency for people to say this is too much and I won' do it. I field questions along the lines of "translating PDF isn' enough - why?" You have to check a bunch of things. Brain surgery is really hard, but it doesn't mean you shouldn't try
JB It's hard, and I would like us to come as close to clarity as we can. I feel like the discussion is valuable to figure out if there is additional clarity we can get that will ensure that it is implemeneted as well as possible in as many tools as possible. THe questions coming up are interessting and may result in a better document.
IJ Phill, you said that the long laundry list of comments that say "did you check this" is not effective. I agree, and it suggests there is work that needs to be done on the user interface. Good design is one issue - show them good design rather than long lists, but the question is whether it is technologically possible. That' less my concern than usability studies should be done on bobby results
PJ I agree that good design is imortant and I was suggesting that we should ask tool developers to do good design, and I was suggesting that we should say which techniques not to use. For example we could say it is a bad approach to use lists, but then what is left? I don' think there are enough technological lists left. The human involvement is what' required, so the tool should take a back seat
JR 4.1 says bring it to the attention of the author that it might be a problem
PJ We need a better way than a list
JR That seems to be a competitiive difference between products how you do it. Some tools will do it well, some will do it adly
CMN I agree with Jan. Having a laundry list is not great, but having nothing is worse
PJ So should 14.2 - use clear language, be in the laundry list?
DB I haven't taken that specifically to developers, but I think they wouldn' agree with that
CMN The MS Word team would be upset if you didn' recognise that they had done a whole lot of that.
DB levle of usability isn' the same as grammar checking
GR That' a multi-level appproach?
PJ SWHould it be on the tool list?
JR It should be on the list
PJ I am saying not every WCAG checkpoint should be on the list
GR Integrate the requirements.
PJ The only thing that would apply to 14.1 is to put it in the help. THis is the level of specificity we need to arrive at in this WG>
CMN We are bound to accept WCAG (by process) and that chages from time to time perhaps. But I think we need to put everything in somewhere - otherwise the tool fails
PJ The question is which ones are on the laundry list?
JR That is a feature of a tool that makes it better or worse
PJ SO tools could get away with making the author check everything?
CMN Yes, although people would throw the tool in the rubbish bin.
PJ So why is 4.1 even in the list if all they have to do is point to the help?
CMN Because it is possible to make a piece of rubbish that works
DB Allowing different levels of quality for conformance doesn't seem right
PJ I think leaving it up to the vendor means the guidelines aren't clear enough and we have to fix that
PJ We agree that everything should be on the laundry list of how to do it, now what hs to be on the machine checking requirements.
JR THere are some things that have to be automatically checked via guidelines 1.
PJ I thought that this was only requiring a capability, not necessarily that it does it automagically
CMN I think that is a stretched reading. But in general, I think the question of testing WCAG is one of state of the art, and we should not be making the decisions
PJ THe question is which ones should be checked for.
IJ I keep hearing that it boils down to what is machine checkable
CMN We are agreed, as I understand it that we should discuss the entire range of WCAG requirements, for example in fulfilling 4.2
PJ I am looking at whether it should be checked byb the tool or not?
IJ It sounds like Phill is sayuing these guidelines as is aren' useable by developers becuse all the stuff that is variable is hard to track down and open to too much interpretation. Phill?
PJ I don' know that anyone has gone into the WCAG techniques other than me
/*WC joins
CMN I am concerned if they are not reading all this
PJ THey said do I have to check for all 66 checkpoints and said not all of them because some are not checkable
IJ I agree that it is not appropriate to have a list of all checkable checkpoints. THe salient theme is that which is machine checkable. Should we introduce that information? It is not in the document, because one tool developer won' have the resources to do things, and the details change. THe two pieces are telling developers there is a minimum, and that is machine-checkability. After that they can distinguish themselves by innovation. We are not going to say what is machine-checkable. That would be my proposal to help developers. I don' know if that should be a note, a requirement. If you make it a requirement and then don't define it do we get back into the same hole.
JB I like the sound of this
PJ me too.
IJ It may nt be unreasonable to raise the normality of that
PJ Does that mean something like the matrix would be a note we would point to?
IJ Sure
PJ Should it be separate
CMN If we point to this then it would need to be updated consistently. I don't think we should be making the decision about what is appropriate to be included
PJ So I was trying to do that with the matrix. If the author has responsisilbity then the tool doesn' have to involve itself
IJ So the tool needn't do things even though they are there
PJ There seemed to be some checkpoints in WCAG that were not applicable - for example some things for ATAG 3.1
IJ The qestion of applicability is fascinating me. It seems to be fundamental to the User Agent guidelines. Almost every last call reviewer had comments on applicability provision. I had proposed a much simpler one for AU. Charles said (and noone opposed it) we don't need that. Should we mak the ffort to pick out the most applicable or do we leave it to common sense. If that's the case I don't know why we shouldn't have te matrix and say this is common sense
PJ THe matrix is the information we use to make the summary statement
IJ What woud the example of the summary statement be?
PJ The tool should check the following WCAG checkpoints...
IJ Things in markup. It can be reduced quickly
PJ Point to somewhere that has a list of those things.
IJ You are saying "or those things that can be checked automatically, do.
PJ And point to the lists for HTML, etc
IJ So the note in 4.1 might be expanded to talk about markup features
CMN I have an objection, but go on
IJ THere may be other things in the techniques that you can add.
PJ So we have markup check, and some machine-checkable semantic checking (but I don't think we have notes on that).
CMN W3C doesn't write notes about those, but there are good references.
CMN Your proposal Phill is to drop any 4.1 support for things that are not machine checkable?
IJ We could modify it to provide methods for other examples of accessibility stuff. You don't have to do more than draw attention to additional problems.
CMN We should check each and every WCAG checkpoint, and whether that is done by machine or by harassing authors, the requirement is to do it for all of them.
JR I agree. The tool is the only contact the author has - there should be an alert even if there are things that cannot be mechanically checked
CMN As I understand it, there is a proposal to say "as well as, or instead of, harassing the author for each thing, there is a requirement to build in machine checking for everything that is machine-checkability"
JR That would be ridiculous as a requirement - what is checkable at Stanford is not reasonable for a small developer
PJ So we are coming back to the matrix and seeing what has to be done.
JR Things move from the practically impossible to the practical
JB Do we ahve the best setup for how develpoers should approach the state of the art
PJ We could add some statements about this being a minimum and we encourage people to go beyond them. At a minimum the ones we agree with are the syntactic checking and there are semantic ones that we have to resolve. There are semantic things that are a lot harder to machine check.
IJ One though is to break down the verb check. I think Charles is using it in the most abstract form which includes asking the author. It might be that if it is broken down at the verb level that there is additional clarity. I hesitate to do it becuase you lose the abstraction. It should be defined in the document anyway.
PJ Do we have ask the user, machine-checkable sytax, machine-checkable semantics
JR I think that is a good idea
IJ The grouping sounds nice but how do we make sure we get everything
PJ We go through WCAG and apply the groupings
CMN I am happy about explaining that there are these different aproaches to checking, but I am very disturbed by the idea that we define the boundaries for developers
IJ ??? - Sribe missed comment
PJ If we could agree on wat is appropriate for developers to do in the yera 2000 then it would be reasily achievable. SHould we have a framework for how to decide? I didn' write down the assumptions I was using. If we can come up with an agreed framework it would be easier
JB What you are proposing sounds exactly like a regulatory phase-in and I think that is the opposite direction to what the group has been trying. My understandig is that the group is trying to map out requirements for functionality. If you look at prescription for requirements you are talking like regulation for certain countires and situations. I think that is not appropriate for this group.
PJ I appreciate this, but there is something like "until user agents" from WCAG
JB What the group was talking about a few minutes ago in terms of a techniques document having comment abou the fact that the state of th art changes and that there may be information available about staetof the art may be approach. I share concerns about w3c committing to provide the state of the art - there is a resource requirement that we do not have allocated at the moment.
PJ We could cover the initial version
CMN I would be surprised
PJ I mean the matrix. There are some detailed comments that need to be added
JB That's up to this WG to be able to answer.
PJ THe evaluation techniques is really 4.1
CMN We poiint to that and that seems about the right level
PJ We could split the WCAG into 3 things - machine checkable by suntax, machine-cheackable semantics, author-checkable
Action PJ: Add the categories to the matrix
Action CMN: Attempt a definition for 4.1 checking that discusses 3 types of checkability.
/* Phill comment about minimal support of author */
CMN: The minimum level of support (to guide the author) applies to every checkpoint. In a number of places, the tool can do better. In the Techs document, we attempt to provide more information about what can be done that don't involve harassing the author. The minimum is helping the author.
PJ: Take "check for in alert", "help create structured content", etc. Do I need to implement something different and unique for each ATAG checkpoint?
CMN: No, you could satisfy 12 checkpoints with one piece of work.
PJ: Is that what we intended?
CMN: But your arrival at this assumption at minimal requirements is different than my assumption and we're in the same WG. I talked with 2 teams of developers at IBM (Japan v. US) and one WG felt pessimistic (can't do anything), another was optimistic.
IJ: Add to FAQ.
CMN: At what point to we stop adding things in? (what is the scope of the guidelines). If we cover HTML, we either have to do the same thing for every language, or we are not doing the job for everyone.
PJ: We have to at least cover what WCAG does.
CMN: What is the role of this WG? It's not the role of this WG to write WCAG. W3C Process gave us WCAG. The requirements of WCAG may change. PJ hit the nail on the head: do we have to cover all the WCAG checkpoints. I say yes, absolutely. If it's a requirement that we simply ignore, then we haven't done our job. If the tools does a bad job, that means that tool is not a good one. If it doesn't do one at all, there's a fundamental failure.
CMN: What is machine checkable? I don't think that's appropriate for these guidelines. The more work we can do to help the better, but I don't believe that it has a place in the document.
Ian Proposes:
Minimum is to check automatically: 1) Check what is machine checkable in markup language (minimal)
Minimum is to inform the user: 2) Check what is semantic (calculable, Desirable) 3) Other
Last Modified $Date: 2000/11/08 08:11:51 $