W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 26 May 1999

Details

Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca

Date: Wednesday 26 May 1999

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

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

Agenda

Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990521.

Attendance

Regrets

Action Items and Resolutions

Minutes

Should the user be able to disable accessibility warnings?

JT: Currently it is implicitly possible

CMN There is simply no resolution - are we happy with the way it is?

Resolved: Leave as is (i.e. implicitly possible)

New Checkpoint for 2.3 - allow the user to edit alternative content

CMN This seemed really obvious, but isn't covered anywhere

JT The assumption is that it is covered in WCAG. Do we need to be explicit?

WL Can't produce without editing

GR Editing?

JR If we go in here we should go into other obvious stuff

GR I think we should keep it implicit in the checkpoints, make it explicit in the techniques

IJ: 2.5.2 - does generation mean authoring of? You might extend that to cover editing...

JT That still doesn't cover the problem.

CMN Agree

JR 2.4 assumes ability to edit

EH This goes back to previous draft, following a significant rewrite

JT If we're going to put it somewhere it belongs in 2.4.7

GR 2.4.8 says it explicitly

WL But that is P3.

CMN It is a clear P1. The question is whether we need it.

JR I don't think it belongs in 2.3 - maybe in 2.4

JT The danger I see is that if we are explicit with this we will be explicit with everything.

CMN That seems an argument for putting it in - then we can see whether there are other assumptions we should be making explicit, or whether these things are so obvious that can leave them out

EH Agree

WC Do we want them in checkpoints?

CMN This is the kind of beasty that checkpoints are made of.

WC I don't know that it shouldn't be a checkpoint - should we look at the other checkpoints and see if it is covered already?

GR There is a technique at the end of 2.4, and it probably belongs there.

CMN This is not really a technique, it is really a checkpoint.

EH It appears there are some thing that are implicit that would be good to state. My feeling is that at the moment we should put it in and see how it looks.

Proposal: Make it checkpoint in 2.4

in favour CMN, JA, EH

against GR, WL

GR We should address it in the introduction.

JT Counter proposal - put it into the introduction of 2.4

CMN It seems that at the moment it is possible to build a conformant tool and not allow the editing of it.

/* Kynn Joins

JR I know it has to be done but I could see how it could be done in introduction.

EH One possibilty is to have a checkpoint that covers everything - allow the author to create, modify and delete the alternative content.

JR Putting in another checkpoint wouldn't hurt too much, and we can take it out if we don't need it.

IJ: 2.4.8 says provide a mechanism... Does that satisfy it?

CMN No, it is only a P3

Proposal: Add checkpoint 2.4.x: "Allow author to edit alternative content." with note that it is a candidate for removal

So Resolved: (WL Dissenting)

Guidelines Introduction and Abstract

EH: I think it was trying to lead off with a sentence that explains what the document is about, then proceeds to tell two main purposes.

JR: I like that

IJ Abstract and Introduction are different - Abstract is a summary of the Document, Introduction is to lead into the document - background, etc.

JT: Separate. Are the abstract and Intro the same? Then what should be in them.

EH I used the same paragraph as beginning of abstract and introduction. I would prefer to have the abstract and intro a bit different. It is very normal to have the key part of anabstract match an intro

CMN I think that repeating the same sentences is a bad idea. I also think Ian is right about the Introduction leading into the document, while the abstract is a summary of the entire thing.

CMN The basic suggestion is a trimming of the intro to the guidelines, and having only one introduction for the whole document.

GR I think that makes it stronger

JR I like that

JA Me Too

IJ Hyuh Hyuh Hyuh Hyuh Hyuh

EH Question. I think there are different assumptions between priorities for user interface and accessibility of content. That needs to be somewhere.

CMN There is a section on priorities, which is where that belongs

EH OK, so I think it is fine...

Resolved: Introduction to be taken from proposal, introduction to guidelines will be removed.

Abstract

CMN I specifically removed the reference to helping the rest of the world because it is either beyond our scope or redundant.

EH I have no problem with that

WL I'm glad it is out.

GR Does the proposal keep the statement "it is expected that the adoption of these guidelines will result in the proliferation of accessible web content"

CMN No, but it should go back there in place of my reference to Web Content

GR I like the first para of Eric's, and the second para of the current version.

GR I think it is indispensible that we make the point about all people being authors in teh abstract.

CMN Propose to send the Abstract back to list:

So Resolved

Merger of 2.6 into 2.7 and 2.3

JT We cannot refer to a document other than a W3C document

IJ Do accessible things for standards makes sense to me. There should be a preference for W3C specs because they have accessibility built in.

CMN I think the restriction to W3C stuff is artificial. It doesn't apply to the current 2.6...

GR If the guideline said "implement all accessible authoring practices for languages handled by the tool" would it solve the problem?

EH Sounds good

GR When I read 2.3.1 it is broader than the guideline scope.

Resolved: Swap titles of 2.3 and 2.3.1

JT The major purpose of 2.6 was to deal with the conversion tools

GR I think we have to address the conversion tools explicitly in a guideline.

CMN I think the proposal would make that explicit within 2.3

GR I would buy that if we take the intro from 2.6 and fold it into abstract

JT The gist ofg 2.3 is more about authoring practices

JR But there are templates in tehre already. We should keep the intro

CMN I would bring the intro to 2.6 into 2.3 as well.

JR I think that then the addition will make the checking and repair section stronger as well.

Proposal: Move checkpoints 2.6.1 and 2.6.2 into a single 2.3 checkpoint, as per proposal, along with intro text from 2.6

JR I'd like to keep them separate.

Proposal: Move checkpoints 2.6.1 and 2.6.2 into 2.3, along with intro text from 2.6, and move 2.6.3 into 2.7

So resolved

What does "recognise accessibility markup" mean?

CMN If you convert something with accessibility content, that accessibility content must feature in the output

IJ Export is better, and retain is better. But then why is it different from 2.6.2?

CMN It isn't - which is why I proposed mergin them.

IJ That works for me.

Resolved: CMN to propose new wording for merged guidelines which focuses on converting

JT Is there something that would be covered in 2.6.2 that would be lost - in making a transformation within a language

CMN That can be covered in one checkpoint

EH What about 'preserving the accessibility function'

CMN That is helpful

IJ So if you don't know about it, you'll lose it, if you do, it is covered.

/* Jim leaves

Remove sample implementations to techniques

WL Yes

Resolved: Remove sample implementation to techniques doc.

Dropping 2.1.4, changing 2.1.3 to P2

JT This is from 2.1 - can we defer it until we have Bruce and Phill?

Resolved: Defer to next week

Other Business

WL I think the relative priority thing would be better handled with a priority R defined once, than multiple checkpoints

JT At the moment we state the P1, P2 and P3 versions of the checkpoints which have multiple flavours

CMN I think it overloads the document

GR Me too

JT Me too

JT Options are to have a single checkpoint with three phrases, or to have a general definition of priority R

JR or P1/2/3

JT Or have if then statements

CMN I think the idea was that it would be easier to have the statement in each checkpoint, and it turns out to be repeated again and again.

Resolved: Have a multiple priority on each relative checkpoint

IJ regrets for next week

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