WAI Authoring Tool Guidelines Working Group
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
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.
Note: Participants did not identify themselves before speaking. IJ, KB, DB statements may be wrongly attributed
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
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
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>>
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
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)
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
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile