W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 16 June 1999

Details

Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>

Date: Wednesday 16 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-19990610.


Attendance


Action Items and Resolutions


Minutes

Definitions section

CMN: The rationale for my proposed changes are to only define things which are important terms used in the document - we can trim the rest. We should leave definitions alone in techniques (as decided last week).

WL The old definitions are much shorter

JT We are taking out user-configurable schedule

CMN Yes. I think that info should be in the techniques section. I think we should move technique information to the techniques where possible, and should shorten the definitions.

JT I am not sure that we want to make the definitions terse in the same way as we do the guidelines

GR For User-configurable schedule we could move the second and third sentences into techniques.

WL How do you define what needs a definition within the document. User-configurable schedule seems like normal english usage

IJ I agree with William - unless there is specific need to give definition to a term as used within this document, I don't think it needs to be defined - do it in the techniques document.

DB I don't think user-configurable schedule is common english, but user configurable makes sense

CMN I think that is an editorial question, rather than having a definition

WC I prefer having a terse definition

Resolved: Terse definition for user configurable - rest into techniques where appropriate

WL I think the extensions CMN proposed are better in the techniques section.

JT The exception to this is something that encurages you take one action instead of another. Not asking information but guiding a choice

DB Maybe better to say a request for a decision, rather than for information

CMN I think it shouold cover both cases

Resolved: Editors look at prompt and alert.

WC Does the terse definition of alert combine all the types of alerts?

CMN Yes

JT the terse definition applies to batched alerts

CMN the proposed definition allows for both intrusive and unintrusive definitions.

JT Markup editing tools and functions - charles has proposed to define authoring tools as used. Remove transformation?

DB Doesn't your defintion include Notepad too?

CMN I tried to exclude text editors

GR the current definition has a sentence to exclude hand-made HTML. Do we keep that.

JT Didn't we talk about this and decide that those tools don't support HTML tools we can still include them?

CMN On the one hand, I don't see a problem with including Notepad- these guidelines apply if Microsoft wants to advertise Notepad as a web authoring tool that complies to double-A (for example)

DB So what is the change?

CMN The scope defines it to mean a lot of types, so we should reflect that in the definition used

WL Why have it at all?

CMN Because the term is used with a specific meaning

Resolved: We want one definition of authoring tools, which matches what we say in the scope.

JT And we want to keep transformation, and there is also "automated markup insertion function". Should we cover that in the authoring tool definition?

IJ If the guidelines requires it to stand on its own it should be covered somewhere.

GR There isn't a specific instance of that in the guidelines

JT I think it is a legacy thing

CMN I think it is still used in some techniques.

Resolved: "Automated markup function" only stays in techniques.

DB Can we discuss scope for a minute? Image editors don't seem to be applicable here.

WL Why not just remove the word "especially" from that?

DB Images are just dragged in.

CMN I don't think there is a lot you can do in the area of gif and jpg, although there are features in those formats. There is a lot more relevance in rich image formats like SVG and CGM

DB I think that stretches the boundary...

CMN Where an image editor wants to claim conformance, that is or should be possible, and tehre are things they should have to do for that.

Action DB: Write this up for the list

GR I like CMN's proposal

WC I think a document is a collection of resources. I find it hard to see image as a document in the normal use of the word. If you want to say resource.

CMN If we do that we need to add the term resource throughout the document.

WL An image is an element within a document.

CMN But it may be the document, and if it is we should define it becuase it is not a common usage.

WC I don't see an SVG as an image. As long as you call a document an element or series of elements it can cascade

GR I am happy with WL and WC's definition, as long as the usage of a document to include an SVG in the techniques. Propose putting CMN's deifnition into techniques.

CMN I'd be happy with that.

WC Document implies text to me. The distinction is that authoring tools are creating things and if it creates an SVG it must include the appropriate text definition.

GR If you open a gif in an image editor, there can be copyright(etc) information.

JT I had a look at WCAG and they have good definitions for the use of document, content, structure, presentation.

GR I hae started to look at this five times and each time it becomes irrelevant. So I think we should do it before we issue another public working draft.

Action JT: Look at Web Content guidelines and see if we can use their definitions.

Resolved: Current definitions stay for document, element, etc.

JT Anyone for an action item to define disability?

IJ Web Content guidelines say "content is accessible when it can be used by a person with disability". We could say "the tool is accessible when it can be used by somebody with a disablity?

DB You're jumping into a tricky area with such a simple definition

CMN I'd like to see someone take an action item, because I think this is a tricky area.

GR I don't think it is possible to define accessibility, and is a red herring.

JT It makes the distinction that we are talking about access for people with disabilities, rather than economic ability etc. Do we want to address that in our definition?

CMN I think we should point out the restriction on the meaning which we are working with.

DB I thought you just wanted to make the context clear without actually saying what it means

CMN I agree

JT In the abstract?

CMN I think we should restate that in the definitions?

Resolved: Editors to produce a 'definition' of accessibility which sets the context but does not attempt to define a meaning.

GR are we going to retain the placeholder for the pointer to the Web Content guidelines?

JT Do we want to leave "accessibility Awareness" in?

CMN Within the context that we use it, I think it is plain english.

JT Do we still have the term in the document?

GR No.

WL One of the things we have in mnd is to raise the awareness of the authors using the tool.

JT We used it to mean that and to define an "accessibility aware tool"

CMN Which I think means either we have lost the idea, or we have explained it without needing a defined term

JT I think the term accessible authoring practices is used, and we need to keep that.

GR The current definition is self-referential.

Resolved: We do need to define accessible authoring practice, more carefully than it currently is.

Resolved: Remove "inserting" and "editing".

Resolved: Remove selection, current selection, focus. If we don't use them, remove "rendered view, etc"

Priority of other documents

CMN This adds relativity to the priority of a particular, apllicable requirement

GR Doesn't the term applicability cover it?

CMN No.

WL The applicable requirement may be P2 but the checkpoint is P1

BR There is no definition of priority in the IBM guidelines...

JT So we say it is crucial, important, or beneficial

IJ I have a problem with that. This group should define as much as possible what we mean.

JT I agree that this is a realtive priority. Would it be helpful if we defined the critical/important/beneficial in the way that the web content guidelines do it?

CMN The problem here is the relativity. We need some way to do that, because it makes no sense to make a P1 requirement of something which happens to be in a set of applicable guidelines which is simply beneficial, but not important or crucial.

GR What we really want is to get people to use all applicable standards for which they are developing, and to ustilise standard programming interface procedures for that program. We made this very terse, and this has suffered.

WL Expanding it out doesn't work - it still doesn't make the need for indexed tabbing anything but P1

CMN I think as we do it here there are plain english explanations, and that would be workable

BR I think that is workable

GR My understanding is that applicable modifies operating system, and all accesibility conventions means all defined. So I would break this into two checkpoints.

CMN I don't think they need to be separated.

JT The other thing is that following standards helps accessibility.

WL The priority relativism is put on the shoulders of the developer

JT The reader of this document

WL That's OK to me, unless we have a 15 month delay.

JT The risk is that someone doesn't understand a barrier. The other side is that we could be overstating the case

GR Sounds like what you described could be spun off into a note

IJ I'm not entirely convinced that the primary problem is the priority. Suppose you have a set of guidelines that has the four things to do, and there are four, unimportant things in there. Do those, and you are done. Even if that doesn't help anyone. I don't see how the priorit of the things carry to these guidelines. But you do have to do everything that is applicable. Priority is not an issue - you do what you should for the platform

CMN I disagree violently. I think there are guidelines which are applicable to almost all types of software. The priority stuff is important, and this seems like the best way to produce a workable document in a useful time, since saying "everything is P1" is wrong.

DB I think the text from the introduction is better.

IJ I don't think it is in W3C's purview to prioritise accessibility guidelines from vendors. The priority is that system conventions be followed. I don't see how to migrate the priority deifintions to the guidelines of other organisations.

CMN I think that places an unreasonable burden - where you follow other guidelines, the bar becomes too high.

IJ Yes. What else can we do?

JT And we are not giving them the expertise they want by that.

DB They are not necessarily coming to us for that advice about application accessibility.

GR Propose that we eliminate 2.1.1 in the checkpoints.

CMN No. These things are checkable, but it is hard

IJ, DB Agree

2.1.3 Wording

CMN I don't like the wording in this - I far prefer Gregory's wording.

Resolved: Adopt the wording proposed by Gregory.


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