W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 2 June 1999

Details

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

Date: Wednesday 2 June 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-19990527.


Attendance

Regrets


Action Items and Resolutions


Minutes

Guideline 2.3

CMN We now have no checkpoint sayig support accessible authoring practices for non-W3C stuff

GR Having a general statement as a guideline is good. I would vote against changing it.

JT Proposal is to make Guideline "support all accessible authoring practices"

GR: That's ok So 2.3.1 would say "support all accessible authoring practices in languages supported by the tool" That's fine by me

JR I have a problem saying "all" in the guideline title

CMN The guideline title isn't that critical - it is a general principle. The checkpoints are what has to be done.

GR OK

JT There won't be a checkpoint referring to W3C recs?

CMN No. There will be references in teh techniques to specifc definitions..

Resolved: 2.3 to be "Support accessible Authoring Practices". 2.3.1 to be the present title of the Guideline.

Checkpoints 2.3.4, 2.3.5 merged and placed into 2.4

GR I think that we are talking about two distinct but related things. We are saying the tool has to recognise the accessiblity markup for imported/converted languages, and that accessibility features need to be preserved. I like the separation.

WL Why isn't that an import?

JA If you open something in Frontpage it trashes your markup. That doesn't mean import to me.

WL An import is opening a file.

CMN I really like Wendy's proposal.

WC Yes. I think that covers the problem Gregory and Jim are talking about.

JR I think that is good, but I think it should stay in 2.3

GR If anything was going into 2.4 I would move 2.3.5

JR I think 2.4 is mainly about descriptive content

JT And structural stuff

WC I prefer it in 2.3

JT Do we say content, or content and structure?

CMN I proposed "preserve accessibility features of content during conversion and transformations" (in the broad sense of content)

JA I think we should leave it as content and leave the issue of the meaning to later

Resolved: 2.3.4 and 2.3.5 to become 2.3.4 Preserve accessible content during conversions and transformations

GR I have a problem - we dont have a definition of transformation anywhere.

JT Should we add a definition?

CMN Yes, I think it is a good idea

Action Gregory: Propose definition of transformations.

CMN We should probably go through definitions section very carefully for next week.

/*Process: JT Will be talking to the King of Sweden for next week's meeting. CMN to chair meeting. JA will take minutes

Guideline 2.1

WL We are facing the first example of a chance to do something about the accessibility of software. WAI has done nothing about software in general. Any chipping away at this should be resisted.

CMN The techniques stuff there comes from my draft of a Note, following my action item to look at doing that with Ian. They are based on a large number of guidelines (references have been sent to email list)

/* KB leaves temporarily

CMN I would make a slight change to my proposal for 2.1.1 to include application guidelines.

GR I can see that - 2.1.2 is a technique for 2.1.1 And User Agent Guidelines are GUI oriented.

CMN And they are not a recommendation yet. Hopefully we will be there when they are.

JT The rationale for this was that User Agent Guidelines would be a stablereference document.

CMN It seems that this document is not stable, so we could refer to it in techniques.

JR I think it shoud remain a checkpoint - it is the only W3C software guideline we have to look at. I also don't like the proposed 2.1.1...

WL Does 2.1.1 get covered in the user agent guidelines?

CMN The dependency is ill-defined. If we let go of them, we are freed from waiting for them

JT We can trust in the W3C process to do ensure the document is OK

JR You may have an authoring tool that has no browser functionality.

JT 2.1.1 is not covered by 2.1.2. Is 2.1.2 covered by 2.1.1?

CMN I think 2.1.1 can be covered by 2.1.1

GR I lean to making 2.1.2 a technique for 2.1.1 My understanding is to go here from General to specific. We start with the General things, then address authoring tools. 2.1.2 says "if the tool has an extra functionality (as a user agent)" - that is less general than other authoring tool specific requirements we have. So moving it down the list will go towards solving the problem

JR So what if we take 2.1.2 and move it further down the list. We could move the actual reference to the techniques.

CMN If we remove the reference then the checkpoint disappears

JT No, it is a functionality

GR I agree - this is a key part of functionality.

CMN OK, so move it down list of 2.1 and leave as is. So also drop proposed 2.1.1

JT dropping that means there is no reference to accessibility standards, and no reference to platform the tool runs on.

CMN I dropped "the platform the tool runs on" because it seemed so obvious, and had accessibility standards in proposed 2.1.1

Proposal: Use operating system and accessibility standards and conventions

GR should still have "all appropriate". I don't know that we should change it or we'll lose something

WC In the case of Java does that break that?

GR OK, so we should have Use all applicable operating system and accessibility standards and conventions

JT Who defines applicable

CMN Applicable means "those which can be applied".

Resolved: 2.1.1 Use all applicable operating system and accessibility standards and conventions.

CMN Proposal for moving 2.1.3 comes from talking to Phill. It is redundant with 2.1.5

JT You could use a tool and get at the property of a particular element. What we are addressing here is to have a completely different view so I can see everything. That is convenient. That has to be separate from how it is published.

JR This is important to keep.

CMN I agree I think it is P2 or P3

GR No

JT This gets to the heart of the problem - it allows the author to create things

CMN No. Being able to access the propoerties and edit them is necessary. Having a convenient view is important.

GR If I ahve a contract to design a site and have to use a horrible background image and colour scheme, I should be able to change the rendering so I can see these things while I am editing them

WL Hence 2.1.5

GR No. 2.1.3 is rendering of the document being edited.

CMN I can see this

JR It is different from deciding the colour - it is being able to edit.

JT It is being able to see the document, not just edit the document.

JA I need 24 point on the screen. In current WYSIWYG editors if I put 24 pt font, everything gets changed

CMN Yes, I agree with that.

CMN 2.1.4 seems a technique for 2.1.3

JT, JA, WL agree

GR I don't think we can lose it. We lose the bit about tags

JR isn't that already in 2.1.3 - the alternate rendering can be textual

JT You may want the image and the graphic

JR The properties are available under 2.1.5. The rendering is covered 2.1.3

GR I don't think so. I think it is too broad. There is a discontinuity between that and 2.1.5. 2.1.4 should say ...

CMN it needs to be clear that the rendering of the properties is accessible - is that what you are saying?

GR Not quite.

JT Are we counting a text equivalent as a property? There are instances where you want both

CMN Yes. I agree with Jan - the rendered version is available from 2.1.3, the text equivalent is there from 2.1.5.

GR I think it needs to be there "allow the author to display a textual equivalent of each element while editing.

JR A developer might wonder what 2.1.3 was there for

WL There are a number of intertwined "definitions" here.

JR If you pull text equivalence out and make it a checkpoint? It is a technique for 2.1.3

Action GR: Propose new wording for 2.1.3, 2.1.4, 2.1.5

CMN I assume that 2.1.5 means edit propoerties

JT This is for pre-packaged alternative content. in terms of 2.1 it is about reading.

JR I see CMN's point. We should be asking here for all properties

JT In 2.1 we are looking at equivalent practise.

JR Because we ask for access..

CMN I think we should say accessible including editable in this section.

JR I think we should say that pre-written alternative content should be editable in 2.4

JT In 2.1 we are saying make sure that everybody has equivalent access to the authoring process. Outside that we are specifying the practices you should include

WL This came up because there are tools that don't let you edit alternative content.

GR I would say 2.4.1 is misplaced - it should be after 2.4.3 and should include "structural information".

CMN I would buy that

Resolved: 2.4.1 moved to after current 2.4.3 and add "structural information" to wording of it.

Action everyone: Review Definitions, and techniques 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