1 December 1999 AU telecon


  1. Jutta
  2. Phil Jenkins
  3. Wendy Chisholm
  4. Judy Brewer
  5. William Loughborough
  6. Charles McCathieNevile
  7. Ian Jacobs
  8. Bruce Roberts
  9. Gregory Rosmaita
  10. Kynn Bartlett
  11. Dick Brown

Summary of action items

  1. PJ put together matrix
  2. JT clear up note for 4.1. make the author decision more specific.
  3. CMN look into language of checklist (should notes be included) and alert the other guidelines groups as well.
  4. Meetings next week:
  5. The group should review and comment on UA.

Responsibility matrix

PJ characterize the task that developers and i going through. when going through each checkpoint, e.g. "check that the content is accessible." therefore, i need to check that "alt" is on IMG. This is the same list of the ERT. As went through each checkpoint trying to determine if the tool should check or the author. We were having disagreements about whose job it was. Therefore, since we're going back to the WCAG and WCAG doesn't say whose job it is, I proposed a matrix.

e.g. 4.1 "check for accessible content." i would take this and compare to the WCAG checkpoint and determine which the author should take care of and which the tool should take care of.

e.g. if i am changing language from english to french on the fly, the tool would not be able to catch this and prompt you.

ERT did not document it this way, just going through techniques. I don't want to include the techniques, but which specific WCAG checkpoints are we expecting the tool to implement.

JT what about "it depends on the tool."

PJ if someone can give me an example, I'll address it. if it does checking, then what should it check for? like the other checkpoints where if the funcitonality not there, it doens't have to comply.

for documentation, required. for checking, not possible therefore not required. would be answered the same regardless of the tool.

GR re: changes in natural language could be addressed by natural language. if use an extended ascii character or quote outside of tag, it says it's an error and fix it. therefore, when these encountered the tool could prompt for fix.

PJ that's a technique. do i have to do that to satisfy this checkpoint?

/* many say yes */

CMN could do something along the lines of Bobby and make a suggestion.

PJ that's a different checkpoint.

JT if read 4.1 says "some cannot be automatic".

PJ then which are the ones that can not be detected automatically?

CMN up to your tool.

PJ how can one do it and another not?

CMN there are heuristics.

PJ there are no tools that can check for natural lang changes. it can guess but can't check. therefore a technique that should not be required.

JT that's the point, hard to create matrix since dependent on tool.

PJ if i check for access, we should check for alt on IMG, and alt on AREA. But that's not specified anywhere.

WL need a list of things that can not be checked for automatically.

PJ i need both. go through WCAG and say which are checkable and which are not. I started the exercise. Everyone agrees it is useful.

CMN yes, it is useful. so is the ERT work.

PJ how determine if we are compliant?

CMN responsibility to test for all P1 checkpoints in WCAG. if test for in completely automatic manner and ask author, or push onto the author and say "please make sure..."

WL "have you checked all the IMGs for alt?"

PJ pushes whole thing to author. is that compliant?

CMN there is not a formal assessment body.

PJ I thought that we could reach a level of consensus on each of the checkpoints.

WL same thing come up for each checkpoint. then check for meaningful alt-text.

PJ ERT has shown that some is machine checkable, some is not.

WL can you find an instance where it is really not checkable?

PJ alt on IMG is clearly checkable. adequacy is a diff check. that level of checking is what is being specified by the ATAG.

JT in terms of alt, that is striaght forward. but lots of grey area. depends on sophistication of the tool.

PJ yes, but I think we should specifiy what level of sophistication we are requiring.

JT two issues. no one disagrees that a matrix would be useful. but is it required to let the guidelines go forward. yesterday, we agreed would be useful, but could not come up with a definitive matrix for all tools. WC and CMN will come up with matrix for 2 types of tools.

PJ instance where checkpoint is not applicable for a certain type of tool.

CMN your example of natural language checking.

PJ we're mixing checking and assisitng. 2 different checkpoints.

CMN possible to develop a tool that heuristically checks for changes in language. you say that unreasonable burden for your tool. you will ask the author instead.

PJ we have to specify whether that is part of the checkpoint or not.

CMN development decision how you get the information from the author.

WL if tool asks the author, then is that complying.

PJ then let's write that down. all that is required is "prompt the author."

JB different understandings of the feasibility of level of implementation as well as how it is complied. can we break this into a couple issues?

PJ there are newer technologies that developers can experiment with to automate, but that level A is not requiring these mechanisms but the minimal prompting.

JT one of the things is that we are not talking about every AU checkpoint,...

PJ yes, i'm concerned only about those that point to WCAG or have relative checkpoints.

JT 3.3 - how would the matrix serve that? why would a matrix be required there?

PJ yes, the content must be compliant. that's what is in the matrix.

JT can't we say that about all WCAG p1's? do you think that a developer would require that matrix to know what to do with 3.3

BR be extremely helpful.

PJ because they need to know what the developer's responsibility is.

JB can we separate some questions?

JT what i wanted to cover:

  1. how critical this is to the forward motion of the document.
  2. which checkpoints in ATAG does the matrix apply to.
  3. relative to the tool and the need for a developer to make some of those decisions.

JB how critical: best addressed after everyone is talking about the same thing.

which items apply to:

PJ has a list.

JB which items apply to. need to flesh out.

relative: needs some time to discuss once we're on the same page.

PJ i like the approach: some of these are easier than others (like 3.3 always yes).

JT 3.1 prompting the author. the tool always has the responsibility to prompt.

PJ disagree.

CMN in practise there are a number of easily defined cases, e.g. whenever you insert a content type that's not HTML. in an image editor, when creating groups, should you prompt the author for text for each group?

PJ valid point.

JB make sense to go through each relative checkpoint?

PJ i listed 8 since it points to WCAG.

IJ if we take "alt" or "lang" even if we provide a matrix, the WCAG checkpoints don't talk about lang specific requirements. e.g. 1.1 says "provide alt text" but doesn't specify for HTML. therefore, in the matrix, are you checking for "lang" or "xml:lang."

/* strange echo - "collective flashback" */

PJ I understand the implementation details still have to be determined by the developer of the tool - whether XML, HTML, etc.

IJ when developer asks "do i have to check for alt on IMG." then they should go to another resource to get that info.

PJ e.g. 4.1 check for and alert. that in WCAG.

IJ might suffice to say, "that which can be checked mechanically"

JT but we have a note, "some require authors to make decisions."

CMN a couple of dependencies: WCAG but also the type of content you are producing. if developer not know the language their tool supposed to produce, they will have a difficult time. we don't say this is how you write HTML, there's a whole spec for that.

PJ whether HTML or XML /* buzz too loud missed end of question */

IJ that level of detail not addressed by WCAG.

PJ is there a way to be general enough, so that when WCAG says "text equivalent" that you have to check for ...

IJ but it is more complicated than the lang attribute. we end up repeating WCAG techniques.

CMN and ERT. another issue: this is describing the state of the art and how close people should go to the state of the art. we're describing a document that does the same thing. we all know what we'd like to see in it. clear consensus that this is useful information.

PJ how do we specify enough info to make it more normative ... checkable .. ??

CMN right, what extent do we need to specify this normatively? that's a question of do these guidelines rely on this info or not? we've been arguing last week that it's up to the developer to decide.

PJ doesn't that leave the door wide open?

CMN yes. we've done that to allow tool developers to make those implementation decisions.

JB is there anywhere that you specify requirements but are not clear what is required?

PJ check for and alert the author to WCAG checkpoints.

JT it's the expanded defn. of "check" - not all are automateable.

PJ so I have to put a Bobby in every tool?

CMN basically. if you look at different versions of bobby, they check in different ways due to the current state of the art.

PJ as an authoring tool developers, I'm not sure when I'm A compliant. I don't think that's good enough. it's inadequate. I know when I'm compliant with HTML. It's very clear.

GR I'm amazed that we're being asked by the tool developers to now provide a list when we they asked us previously not to because they want it open ended. "don't tell us how to do it, just tell us what to check for."

JB but, we're not hearing from all of the developers.

PJ I need to know which of the 66 to check for.

JT all of them.

IJ idea of "applicability" creeping up. this one is applicable because machine checkable, this one just needs a prompt. but may not need to be as big as a matrix. it's the complement of the state of the art of machine-checking.

PJ I think 3.3 is a "yes" all the way across. it doesn't require machine automation.

DB I share this viewpoint to some extent. but, 2.1 - does that mean you have to prompt someone each time they use color. I doubt they would prompt each time someone uses a color.

CMN right. you can put in a check at a scheduled interval. we took it out because we thought it was important to leave open for developers and authors. whether you do it every single time or one time that's a development decision.

DB you'd have to ensure that the author is running the tool at the end. therefore you have to prompt them to run something. therefore, before they close a file you are prompting them for guidelines not checked for they must run a tool.

PJ these are implementation details. but what prompt for is what i'm asking for. there are only 7 or 8 checkpoints that refer to WCAG. 1 or 2 may be quickly eliminated if always "yes" or "no." I could come up with a proposal.

Action PJ put together matrix

CMN also has an action item to do this. is this matrix normative?

PJ when i was going through the natural language it was normative that I know these things.

JT potentially not. once you've completed a draft of the matrix, maybe we should revisit.

PJ I already did for 4.1 and we don't agree. but because we are disagreeing about the state of the art?

CMN what you need to do is "some kind of check." whether it is mechanical or ask the author.

JB i.e. if it is not clear that there is an automatic way to do it, then the developer be responsible for doing it manually. is that capturable?

IJ that suggests that people don't have to impement anything.

JB no - that if there is not something that is automatically checkable across all tools, they are required to do a manually.

CMN another piece: if no mechanical wizardy, then have to implement some way to interact with author to check.

DB even if automatic method, need way to user to interact with result.

PJ thought IJ said, "is that letting the tool vendor with getting away with just reminding author"

IJ because seems that there was a sweeping "if all tools can't do this..."

JB once scenario is multiple levels of clarification: clarifying what "automatic checking" means, the cascade of assumptions (if not way to check auto, ...), providing more guidance as to what we know. not telling the developer HOW to do something, but enriching the guidance.

CMN yes, need a whole doc that does just that.

JT in terms of guidelines 4.1 seems to be the most contentious. can we make the note clearer? that might address some of the issue.

PJ yes, 4.1 across all WCAG is the hardest part to do. assumption in ER..

/* WC discusses ERT and how this sounds like "Readily achievable" in telecomm discussions. */

JT is a comprehensive matrix for the guideliens doc to go forward? does it belong in guidelines or techniques?

PJ those things that are normative (e.g., 3.3) does not need to be elaborate, nor prescriptive. the matrix was an approach to come up w/answer not the answer. matrix is getting simpler.

BR i think the matrix does not need to be in guidelines. it is based on state of the art as well as the tyep of tool. i think it should go in techniques or own associated document. however, guidelines will go forward best if it is available. it makes it accessible to a developer, can point them to a place to start.

PJ if don't have a place to point them to, then how can it move forward?

IJ suggests that doc can't go forward then unless it's available.

JB concept is evolving as we talk. from process viewpoint - w3c has been clear that a guideline document is stand alone. while support materials may be good things to have, to tie the release with this guideline with a technical note i'm not sure it works, although it makes sense in a way. we've been trying not to do that. we need techniques filled out to a certain level. yet, i agree with the comments i'm hearing - it does not sound normative.

BR is there a middle ground? we commit to producing w/in a month or two?

JB that makes more sense. a logistical worry is that it has been hard to get people to input into current techniques doc, can we get the matrix in place? Therefore holding up whole doc for that is tricky.

CMN want to echo what judy said: either guidelines can stand alone as normative doc or can not. we have a commitment to produce a techniques doc. it seems that there is consensus that we should include matrix type of info in the techniques doc. if guidelines depend on it, then it is more than an informative aid.

WL the "check for" (in 4.1) might need some work. that's the only thing i've heard that needs work in the guidelines document.

JT we ought to edit the note that follows it. make the author decision more specific.

Action JT - clear up note for 4.1. make the author decision more specific.

CMN yes, other developers have been clear about but recognize it is not a trivial task. WCAG is a big doc. They have to read ATAG as well as WCAG. There is a lot of work in those assessments, and then implementing those decisions.

BR therefore, PJ is the only one who does not believe it is normative?

PJ if we add to 3.3 and 1.4, "the tool dev. should manually ensure that templates conform."

BR based on phil's work, that may feed back into the guideline. should we reconsider that question?

PJ part of the matrix could be part of a normative piece of info, in addition to clarification on the note in 4.1.

JT in terms of 3.3, or 1.4 i would assume that the assumption is "you have to do it."

CMN it says, "ensure that the templates conform."

PJ yes, those are automatically out of the matrix.

JT then what additional text do we need?

PJ "ensure" means "more than machine checkable." that's not clear.

JT it doesn't say that "check that" it says "ensure" since the developer is creating.

BR PJ, you said the matrix completely normative. (yes) then it goes through more than one or two checkpoints.

CMN matrix being normative, it describes state of the art. if so, then it needs to be updated often. i would like to see a commitment that it will be kept up to date. it also prescribes a dependency on WCAG that does not currently exist. effectively we're saying that "these are the requirements that have to be met, and these will change." but are we saying we'll only do once, doesn't matter what's in the future.

PJ i thought we could be normative and include terms like "readily achievable."

CMN in w3c terms a normative doc can not have a dependency.

JT PJ, what CMN is saying, is that if WCAG changes our checkpoints apply.

PJ i believe the matrix could be created so that they are changeable. perhaps we can group checkpoints in WCAG. if take 7 or 8 in ATAG and compare with 66 in WCAG. the idea was to come up with answer not publish the matrix. a "yes" or "no" in matrix may not be normative. we could characterize what is machine checkable what is not.

JT are you suggesting these illustrative comments should go in guidelines or techniques?

PJ guidelines. techniques would have more detail. which is ERT. e.g, for 4.1 i would like to point to ERT.

JB a personal pespective. i am concerned about the group taking a dependency of the ERT doc. it is in very early stage of development. not only the content but the approach is not fully tested. it is most likely several months from being completed.

PJ I did not mean "dependent" i meant "reference."

JB it is a preliminary draft it may change approach. I hear interest, although no commitments to help work on it.

JT summarize where we are:

CMN are people reading the checklist or the guidelines? the guidelines is the spec not the checklist.

JB if people might be working too directly off of the checklist, then you should change the abstract or add a stronger advisory that the checklist is just a guide to reading the full guidelines.

WC if note makes a difference in interpretation of a checkpoint, notes should be included in checklist.

Action CMN look into language of checklist (should notes be included) and alert the other guidelines groups as well.

JT can you have this done by this week?

PJ concerned about what getting self into. why isn't ERT further along?

GR we are being very methodical. some issues are going back to GL.

JB my understanding is there is good effort but we need more input from developers. people have to be thinking from other perspectives and spread work.

JT 2 of the research groups are also tool developers (CAST and AT).

JB I mean industry developers.

WL we may be clear what the matrix looks like, but the slowness comes from creating actual techniques.

JT yes, not sure if there are only 3 possible states for each node in the matrix.

JB It would be helpful for the working group to have semi-matrix/table to have within the next day or so.

PJ to summarize what i'm going to do: in my original list of 8 checkpoints, i've eliminated 2 (3.3, and 4.x), 4.2 would be a yes. therefore i look at 1.3, 3.1, 3.2, 4.1, 5.2.

JT what is the issue with 5.2?

PJ if prompt you, what prompt you for.

CMN again, can we put the guidelines out without this or do they rely on it? WRT 5.2, how do you meet those requirements in a given language? there are quite a lot of steps to implement.

JT 5.2 depends on the tool. the matrix is not informative of which WCAG it needs to implement. therefore matrix not helpful at all.

CMN the more of the matrix stuff we have, the more helpful it is. however i am not convinced that we need the matrix to release the guidelines. if we do this, it will save developers time.

WL is CMN working on the same matrix as PJ?

CMN no, working on a 66 x 8 x # of tools. super set of PJ's.

JB slight change of topic: if as a WG you are considering enough changes to the doc to significantly change the essence of it, then regardless of what supportive material could be assembled quickly, the doc should be recycled through PR.

JT there have been no changes to the doc. only explanations.

JB none of the contents of the guidelines has changed. if a lot the explanatory material has been changed, you may be changing the way the doc is read.

JT i would like to get general consensus, but i don't think so.

WL editorial.

CMN if we add the matrix, then yes a significant chagne. but if not, only editorial.

PJ I don't know if the changes will require a recycle.

CMN if put matrix in, changes significantly.

JT everyone agree matrix not in guidelines?

PJ for 4.1 want a list.

JB don't ask now, keep in mind.

/* ok. */

CMN addition of that list means we need to send back. they need to look at that list.

PJ is it necessary to have the level of info in the guidelines? if diff developers assessing what is needed ifferently is that indication that we need more info in the doc? when i read other specs, i get a very programmatic idea of what is needed. here there are goals to work on. therefore, the checkpoints need to be checkable.

JT say the same thing for WCAG? yes, which is why we added UUA clauses.

JB the issue is more compounded when software rather than web site. a consistent interpretation is different due to product styles and cycles. if very different interpretations then the group ought to be concerned.

GR however, PJ, look at "accesskey." the HTML spec is vague.

JB that is proving by negative example. that is a known bug.

CMN if people are coming up with contradictory interpretations, then there is clearly a problem. if slightly different... I expect that. One of things we have tried to do with the example conformance reviews is to show people how we are interpretting things. I expect interpretations will change slightly. At the end of the day it is offering guidance.

GR re: negative examples. a state of the art matrix is providing a negative example.

IJ does that mean the state of the art is not good?

GR it's too constraining to fit what we are discussing.

PJ in other words, it's o.k. to have P1 not be readily achievable everywhere? It should be readily achievable, but it may not be. When we say it is readily achievable, that does not mean it is has been achieved in a tool or in every tool.

GR make same argument about CSS.

PJ no one has implemented but it has been specified.

CMN that's a general thing: w3c are not descriptive of what's there, but how to improve the operability...make things better. you can point to lots of specs w/problems (e.g., accesskey in HTML). they thought it was readily achievable. it has been achieved in 2 versions of a tool in 2 different ways.

JB we're seeing some of those groups saying they need to do more work to get them implemented. that doesn't say we need a complete set of everything before go out, but WRT CSS2 it has had a slower implementation. it would have been good for the group to look at implementation. which is what they're doing now. they are loooking to what we are doing for supporting documents.

JT summary:

PJ then how do you determine if you've met it?

IJ reasonable person should be able to determine. Look at techniques.

CMN if you have some kind of check (either mechanical or prompt author to check) if don't, then you don't.

PJ Jutta has taken action to create note for 4.1? does that apply to other checkpoints as well?

CMN in current WCAG a few checkpoints talk about equivalent info. in techniques we should identify those.

PJ let's see where we go from here.

JT you've taken action?

PJ friday i will publish where i'm at. i will not do anything tomorrow due to all day meetings.

Next meeting

JT next meeting: we have a meeting scheduled for next Wednesday. Can we meet before then? 6,7,8?

KB is out of town.

IJ, WC, CMN and WL available.

GR not available on 8th. on 6th there is a PF at 4:00 in the afternoon.

BR not available.

Monday at 3:00 until 4:30. some may leave at 4:00.

Tuesday as well? (DB will join when he can)

Regular time on Wednesday.

UA review

JT UA guideline review. Has anyone reviewed?

GR and CMN has reviewed as UA members.

JB What about as a group?

PJ we have a dependency on them. IJ did you get my review?