W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 24 October 1999

Details

Chair: Charles McCathieNevile

Date: Wednesday 24 November 1999

Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)

Phone number: Tobin Bridge, +1 (617) 252 7000


Agenda

The Latest Draft is the Prposed Recommendation draft dated 26 October, available at http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026.


Attendance

Regrets:


Action Items and Resolutions


Minutes

JB Where are we in the process: The WG had agreed to go to Proposed Recommendation, so the director offered it for review to the Advisory Committee (w3c members). The substance of review comments is how organisations think W3C should deal with the document - make it a recommendation, make minor changes first, return it to the working group to fix things, drop the entire activity, or abstain. There are also comments submitted that are generally confidential. The substance of the comments have been summarised so we can discuss the issues arising from the review.

JB The stage the WG is at now is slightly different - we are no longer in a decision-making process, but we are here to offer our advice to the director on how to respond to the comments and what to do with the document.

WL There is very little in substantive issues raised for the guidelines and a lot to do with techniques. Can this go through as a recommendation?

JB That is probably a key issue. There was some heavy discussion in an AC member forum over the past week. I have looked at that closely and spent lots of time talking to the prganisations involved - at one point i felt that the issues being raised are more of a techniques nature, and could be dealt with exclusively at the level of hte techniques document, and the individuals concerned had not looked sufficiently carefully at the scope. However I think the group needs to look at how the techniques and the guidelines are related, and you may not be able to completely separate them and send out the guideline document.

CMN I think that in terms of the issue, we need to look carefully at it. There is the question of whether the guidelines are sufficient to stand on their own, or do we need further work.

CMN There are a bunch of other issues (reads issue list)

IJ I have changed the scripts so that 7.1 comes out in the P1 list but does not get the P1 marker

JB If you look at the summary of member review comments, it doesn' include all the reviews because some of them had no comments. One of the reviews said the document should be sent back to the working group. It referes to discussion taht took place in a member forum - I hope that we can get that into the working group loop by the end of the period. The issues list includes issues that arose through review, and issues that arose alongside. Everything must be addressed to become a recommendation, but in particular the comments that suggested that the document needs to go back to the working group needs to be thoroughly addressed.

WL What is listed in the "send back to the working group" discussion?

JB It is the issue listed in the Member A comment in the summary of reviews

CMN There are a couple of related issues - that it is possible to see the checkpoints which have relative priority as having 66 parts each (the WCAG checkpoints), so there are a total of around 500 checkpoints. Related to that is that it is not always clear what the tool can do, and what it cannot really find out. The discussion of that issue in a member-only forum ended up around the proposal outlined by Phill at the last face to face and put again by Bruce today.

JB I would like to talk a little about the question of what is the real situation with regard to what is legitimate use.

WL I would like to oppose the suggestion - I do not want to tell any regulatory body what they can or cannot do with our document

JB 2 issues. There was some discussion with one or two organisations about whether these guidelines might be used by other bodies as a "ule-out" or an approaching threshold for procurement needs. That is, if there was no tool which met level-A, would there be no tools bought by a particular body (rule-out) or if there were a couple of tools then the preference would be given to the tool that was closest. There was some discussion that it would be beneficial t add a phrase into the document laong the lines that this document represents a target, and at the time of first publishing there may not be a lot of tools around that meet them. The review comment is more along the lines of "no regulatory process can pouint to these guidelines" which is saying that these cannot set a direction or standard. A second piece of information is that I had been getting curious about how Section 508 (US law which is being discussed at the moment) would work. What i found out is that I could ask some general wquestions from the Access board, and it appears that the way it might work would be very differently than people would be thinking. It apparently is most likely that the relevance for authoring tools will be on the question of uesr interface accessibility, and only indirectly on the ability of the tool to produce accessible content. The pressure for tools that support accessible authring are more likely to come from the need to comply with content requirements, or direct market desire. I think the concern raised in that member comment mioght be out of context.

/*KB joins

JR We should point out that this is not a regulatory document, and beyondf that we don' have any control of how people use it.

WL I don't think we should say it in the document.

GR It isn't a regulatory document

JB I think there are several things to think over on this. Up until WCAG, W3C specifications have been about technical descriptions of languages. WCAG broke new ground for W3C in terms of saying "his is how we think you should build a website. These guidelines break new ground in terms of saying thisis how we think you should make a tool. it is a target. You may want to make it clear in the introduction.

JR You can' stop someone using it.

JB I think the solution for this is not as easy as it might seem. There is a context that needs to be acknowledged

WL Does WCAG say it isn't regulation?

JB No, but it is not applying to software, so the crunch comes onto individual websites. When you are building software the focus is tighter. I think the working group should allocate a little time to this and look at the context these are used in and whether the needs of different types of organisations who will use them are met.

CMN The other issue that we have to address from the request to return it to the working group is the expected level of skill of a user - do we mean the power user, the person who doesn't even know what the softwarre does

WL The language should vary based on the type of the tool. We have written this for authoring tools, and where the functions are performed by word processors perhaps we have to have different language. We have attended carefully to the authoring tool rather than other software.

JB If the guidelines haven't been tested across different types of tool then it is an interesting issue. I know that people assessed different types of tool, but it was people who have a solid understanding of what the checkpoint means for different types of tool.

WL This was discussed a numbr of times through the working of the group. I believe that we have made it so a tool that is bad doesn' qualify.

CMN There are a number of cases where people have asked how particular checkpoints apply in particular situations and we have discussed it on list and in conformance evaluations - maybe the techniques document should point to that discussion.

JB I wonder what we think about the various issues. I am interested in how much work you think there is to address each issue.

Quick review of Issues:

Appropriate Use of Guidelines

JR This isn' a regulatory document, and is a target to aim for

WL That's in there. We have answered this.

JR I don't like the proposal made.

CMN There is a big difference between someone making a stupid and inappropriate use of these and making intelligent reference to them

GR I think that hits it. This is not writing a markup language, but it is outside our scope to say how people can use it. If we are going to put in the statement about a target I would like a pointer to the conformance evaluations to show where we think the state of the art is

DB I agree we should not be telling people what these can be used for. I think we should say something simple in the abstract or introduction.

JB It might be a good thing ot put it in the conformance section because people who are pointing to it will look at that. It sounds like there is pretty common sentiment, and the work and time requirement is getting the right language and settling it nicely.

CMN We sound like we have a common understanding, and we need some editorial back and forth still.

Action IJ, CMN: Make proposal for text about Appropriate Use of Guidelines

Extent of tools responsibility

CMN Should we make up a checklist?

JR I think this is a good idea in the techniques. It will reduce the amount of work developers need to do.

JB I want to raise the possibility that it may not be possible to do this. I am not convinced that this task is a feazsible task, for a few different reasons. There are a huge number of checkpoints, a wide range of tools that may have different needs, and ther are variations on state of the art that will be constantly changing, so there is a resource concern. I hope the working group looks carefully at what the task really means, the feasibility and the resource requirements for keeping a matrix like that up to date. Is there a feasible, simnple version that could be offered as a support piece. Should there be a dependency between the GL and such a techniques document

CMN I think it is possible to make a start at this. There is a questionof wheter we should do it or help ERT. This is a major issue from teh review, so we need to address it carefully

GR I think there is a problem with tying such a matrix as this too closely. WCAG already provides a matrix through its checklist, and wee need to feed into that and ERT, but I don't think our time is worth spending on doing their work.

JB It may be that as you look at the issues and look at how they were expressed you may end up wanting to rename some of them as they shift. My sense from some of the converstaions was that another way to express this is a questrion of is there adequate support for the developer to understand and implement the guidelines. A specific question on that is the responsibility of a given tool. I sahre some of gregory's concerns about tying things together, but maybve the underlying concern is whether there is enough underlying support. Some organisations think there is - it may be impoossible to do this for every tool but that people who know there tool well will be able to figure it out for their type of tool. In the member A comment there is some text that the need for more developer support might be utwieghed by the need to update ATAG with changes to WCAG. Read and listne broadly, because there are a lot of things that interplay.

WL This isn' just realtive proirities, it is also to do with all the WCAG stuff.

JB The issue list may need to shift around to capture the topic.

CMN Does anyone think that the guidelines should depend on such work?

JR No.

WL The ATAG have to refer to WCAG

JR But they don't have to reproduce them - they can refer to them "as they are".

WL Are you going to get a complain about referring to a moving target?

CMN Well yes, but so is HTML a moving target

GR We worked hard to make this stable if things changed, and I think we did a good job of that.

JB That has been acknowledged in converstaions. But look at the third para of member A's comments.

CMN The people here seem to feel that we address that. I think that we need to think about this and look for people who do not agree, and get ourselves convinced otherwise, or build a good explanation of why we think this is not an issue.

JB Warning - the ERT document is a long way from stable at the moment, so depending on it could be a problem. I think there may be several items in the single item listed. You may have "adequacy of support for developers" - there may be enough or you may need to develop more, there is the specific issue of whether a matrix should be available. And should that be part of the guidelines/techniques document? - that sound like the thing that is clearest, but the issues haven' been fully shaken out of the rest yet.

WL We have talked about this a lot and we felt that the guidelines themselves, rather than the techniques or for any tools, don't depend on the existence of those things, so they don' need to be shaken around, although we can work on the techniques (always).

JB I think there are 4 issues:

  1. adequacy of support material
  2. version independence to WCAG
  3. Should we make a matrix of tool requirements
  4. Should that be GL or techniques work

Action CMN: Split the responsibility of the tool developer issue as discussed

CMN An issue that is not on the list yet, the proposal about having a level 0 priority about doing no harm.

Do no harm...

JB I can give background. I was trying to brainstorm solutions. The concern is level of granularity of the priorities and the fact that to get done with P1 you have to do a lot of work. For some developers there is a concern that the jump required for level-A is so high that they will toss out the guidelines as too hard. In asking what would help, there are a lot of different schemes for changes in priority, and a lot won' come near meeting consensus. The one thing that got interesting was the idea that there are enough tools doing bad things like stripping markup that it might be interesting to exlpore a priority 0 level - do no harm. Some companies might want to use it as an internal step to work towards - a preparatory run. It ouwldn' be a high level of bragging

WL So a text editor is a priority 0.

JB If a tool were trying to make some progress that it wouldn' create barriers for access then it maybe helpful to add a baby step

JR Who would really seriously say "level 0 compliance"

JB For additional context the person who was discussing this with me was suggesting to make that P1, move P1 to P2, etc.

JR Not to mention that P1 sounds pretty good

JB That's the background. If it can bring people in without distorting anything then you may want to allocate some time to explore it

JR I would suggest that they just make some statement on the box and refer to the checkpoints

DB I don't think that would make it on a box

JB It is damning with faint praise.

WL The reason not is that there are already tools that are very close.

JB We are having trouble getting hard documentation that there will be tools which actually meet the checkpoints. Saying there will be tools that meet a lot of level-A is not the same thing.

CMN is anyone interested in this?

Nobody seems really interested.

JB I would encourage you to say why you think it is unnecessary and detrimental.

Action GR: Draft a response to the Priority 0 suggestion.

Action CMN: Add the Priority 0 suggestion to the issues list

JR I thought of something - A, double-A, triple-A is opposite to the way baseball works.

WL No it isn't

GR I found it hard to figure out which set means what.

Level of user skill

CMN The average user of the tool might be determined based on who it is marketed to.

WL The simpler the tool to use, the more it needs to do

JR A highly skilled tool user may have low accessibiltiy skills

JB There may be other problems with that model

Linking techniques from checklist

Action CMN: Add the issue of linking from the checklist to the techniques document

CMN It is a case of Ian and I sitting down some script

General agreement if simple

Things that have gone on the email list

general agreement that this is simple

Editorial Comments

WL We can leave that to the editors.

And so...

JB I would be interested if people would look at the issues list itself over the next few days

GR I wouldn't underestimate the complextiy of some of the issues - the fact they took so long to come out reflects that.

JB It may be that the group has consensus in how they are thinking, but haven't got it clearly into the document yet.


Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.


Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile