W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 7 July 1999


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

Date: Wednesday 7 July 1999

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

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


Review of Latest Draft

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

Note that in most cases there is a thread of discussion following the message which has been referred to here.



Action Items and Resolutions


Note: Participants did not identify themselves before speaking. IJ, KB, DB statements may be wrongly attributed

Guideline 2

JT: proposal for 2.2, in addition or replacement

CMN: leave 2.1 as is, change 2.2 to 2 check points, that read 2.2: [Priority 1]

Ensure that content is created in accordance with a published standard. (subtext could go in as a note)

This ensures that it is possible to create User Agents that are aware of the standard being used, and relevant accessibility features. For example, produce content which conforms to a W3C specification (see also 2.1). I think this is sufficiently self-explanatory not to require techniques beyond the example).

and 2.3: [Priority 1]

Do not use a document type which precludes users' access to content or function of the document. (subtext could go in as a note to the checkpoint)

Some document types are inaccessible, and certain modifications to existing types can reduce the accessibility. Both of these cases must be avoided. (The techniques section for 2.2 applies to this checkpoint)

JT: comments on splitting, was discussed at last telecon,

WL: once he clarified what "published" meant, it was ok

CMN: not sure what "published" (resource on the web) means

WL: thought it means, the UA could recognize the thing as an acceptable DTD and parse it

CMN: if built to recognized standard then a UA will read it, best place is the web. standard must be published, accessibility of standard is another checkpoint

CMN: needs to be published in the realm in which it is used.

Jan: is this really P1

CMN: yes

WL: standard must be public so all can see what standard is

Jan: authoring tool maker, must communicate with UA to ensure what the tool makes the UA can read, seems like a gimme

CMN: published, means it is publicly available

Jan: at what cost, what if it is in house,

CMN: if distribution is restricted, then standard could be restricted

JT: what is an example

CMN: many tools use their own DTD, if DTD not available then it fails the checkpoint,

Jan: if Front page produces pages using a proprietary DTD, that only works with IE, totally proprietary, then it fails checkpoint CMN: right

Jan: concern about audience for standard

CMN: acceptable to restrict content model-CIA create DTD - SPYML, not public

Jan: we are not writing how do you make a DTD accessible

CMN: no, to have an authoring tool to create an accessible document then you must be able to find out how the document was put together.

WL: need examples

JT: any other comments, about splitting 2.2 into 2 checkpoints as per above...

IJ: No

Resolved: Split 2.2 into two checkpoints, as proposed

WL: techniques need work

Jan: DTD does not preclude user access

CMN: document type does not mean DTD,

IJ: use markup language rather than document type

JT: don't extent language in an inaccessible way

CMN: yes

Jan: from the start, document

IJ: use and extend mark up languages accessibly, 2 parts if you extend the ml, then ensure its accessibility

JT: this is GL 2, all about standards

CMN: possible to have inaccessible ml, should swap for one that is Jan: like "inherent" inacc

JT: do not use inherently inaccessible ml

Jan: who is going to design something that is inaccessible

JT: can be done by accident

Jan: don't extend in an inaccessible way, where are the guidelines for this

CMN: one in techniques, need to write more, not complex, work going on in another WG (member only), short set of guidelines on how to make accessible DTD

JT: wording for 2.3...

Resolved: new wording 2.3 ensure that document language used enables accessibility of content

JT: other comments? (None)

JT: accept new wording, add subtext....

Action Editors: add subtext, apply to extensions to mark up languages

Checkpoint 1.3

JT: GM proposed 1.3 be split into

1.3 Allow the author to display and edit the properties of each element and object. [Priority 1]

1.X Allow the author to display a non-visual equivalent of each element, object, and property. [Priority 1]

IJ: what does non visual mean

WL: use text for non visual

JT: giving access to object

CMN: proposed 1.x is redundant to existing Checkpoint, but should be a subtext note

JT: should have access to properties,

IJ: why would an app developer not allow author to edit everything

JT: makes a simpler application

CMN: Checkpoint allows ability to change properties, subtext says when ability is available then it must be in an accessible way.

IJ: properties are important

JT: any tool will allow display object, only limited properties are available to editing, need to address editing properties to be done in an accessible manner. Guidelines do not address this problem,

IJ: this should be the case in any application, edit properties in any program

CMN: 1.1 use things which are standard for applications, no harm is stating that editing properties should be done in an accessible manner in the subtext.

IJ: need to be more explicit, edit properties could be use mouse to stretch image,

CMN: get to each object on a page and edit properties

JT: Checkpoint reads display ..., concern was accessible method of editing properties

IJ: what is difference between element and its properties, I'm confused

CMN: Checkpoint requires user be able to change properties of an element, doable in an accessible way
i.e. use mouse to change color on a color wheel, must supply an accessible way,

JT: properties are typically displayed on the screen as they would appear in the browser, how does an author edit the property

IJ: doesn't get to the point

JT: more than textual equivalent, the textual equivalent of the properties, author with a disability needs to have access to information and be able to edit it,

IJ: obvious for all applications, need more specificity

WL: property is different from the element, for the properties of every element and object

Resolved: 1.3 allow author to display and edit all properties of each element and object in an accessible fashion

Techniques reviews:

Guideline 1

WL: 1.1 user focus....moving focus should not cause unexpected events

Jan: follow a path that seems reasonable

CMN: its a long list

Action CMN: clarify what "unexpected events means" in techniques for 1.1

WL: Rendered view may

CMN: techniques are options for tool makers, "may" is appropriate word, don't have to have a rendered view, techniques for P1 say should,

WL: have a presentation independent of "rendered view", should say must

CMN: no technique can be a requirement, can't say MUST, that would make it a requirement and move it to technique.

JT: techniques within 1.1 are ok

WL: Yes.

Action CMN: have additional references for 1.1

<<KB joins>>

Guideline 2

CMN: use w3 specs, should list them, point out things that are moving to REC, point to TR page,

JT: we have 3 Checkpoints, do we need more

CMN: for 2.2 explain how to publish a document, ideal way is to make specification available on the web,
tech for old 2.2 move to 2.3

Action CMN: write expansive explanation "how to make documents more accessible" from PF group, with clarifications about extensions to markup languages

Guidline 3

IJ: 3.1 Implement all accessible authoring practices that have been defined for the markup language(s) supported by the tool. with 4 techniques, add SMIL 1 accessibility features from Marjia and IJ , confirm links work, add link to UAGL, subtext as to why UAGL link is there

JT: why UAGL

IJ: because of "until UA do this" in WCAG, creates dependencies with UAGL, and tool could say we should do this for authors, people don't realize that techniques document exits, need more links

IJ: 3.2,3,4 - add greater emphasis on conformance tools, and validators rather than specific things to do. Point to WCAG techniques.

JT: give examples of what not to do

IJ: i.e.

JT: emphasis on produce,

IJ: emphasis on conform, for produce go to 3.1, for conformance use testing tools,

JT: Link to tools

CMN: repeat links, and point to WCAG

JT: make clear that this is not comprehensive, only a short summary

WL: doesn't it say that in the abstract

JT: in 3.2?

WL: 1 introduction....general suggestions.....

JT: 3 checkpoints, reader doesn't know where they came from, if we summarize WCAG, then we should say that

CMN: explicitly say this is rough summary, point reader to in-depth resources

JT: how does a tool produce content that conforms, what instances does this apply to, how to ensure this happens

IJ: this is about authoring practices, 3.1, 3.2 are about authoring practice

JT: point out when problems occur

IJ: 3.3 what distinguishes template from document, use template repeatedly,

JT: templates are what authors use to do things quickly, content within templates must be accessible

IJ: not much different from a document

CMN: template is a structure and content Provided by tool

IJ: wording is poor

Resolved: change Checkpoint 3.3 to "Ensure that templates provided by the authoring tool conform to WCAG"

IJ: use the WCAG, functionality of using templates

CMN: template is insertion by the tool

IJ: fill out form, or apply it to a database

JT: talking about content created by the template being accessible IJ: all have to meet WCAG

JT: templates are commonly used, make for easy authoring,

CMN: templates are developed by the tool maker, author add information, and template should make it conform to WCAG

IJ: for 3.4 I need more time

action IJ: techniques for 3.4 (think more on this, converting from one format to another)

Guideline 4

DB: alternative content mechanism for storing other content

JT: yes

DB: unreasonable, tool to store lots of additional information, 4.5 mechanism to manage alternative content, what about video clip, does tool need to store all alternative information IJ: store pointer to information

JT: address in techniques how this applies to video, audio

DB: pointer to info is useful

Jan: expect tool to point to sources

Action JR: clarify multimedia alternative storage in 4.5 techniques

DB: 4.4 and 4.6 conflict. alternative content included with tool and automatically generated may be equally less valuable JT: must be editable when it is put in context

Deferred issue for next week 4.4 and 4.6 conflict (provide alternative content, don't include automatically generated text) discuss on list

Tehniques for guidelines 5, 6 and 7 deferred to list/next week


deferred to list/next meeting

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