WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Tuesday 9 February 1999
Time: 3pm - 4pm Boston time (2000Z - 2100Z)
Phone number: Longfellow Bridge, +1 (617) 252 1038
Determine if there is a consensus for any of the proposals on the agenda. This is not an opportunity to discuss the proposal. It simply allows any items for which no discussion is required to be cleared at the beginning of the call.
The latest working group draft is http://www.w3.org/TR/1999/WD-WAI-AUTOOLS-19990128. Where proposals are still current, but were based on old drafts, numbering given here reflects that of the current document.
Proposed by Ian Jacobs - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0028.html:
Proposed by William Loughborough - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0052.html:
Proposed by Daniel Dardailler - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0069.html:
Technique for 2.5: Provide the option of entering Alternatve text or selcting a null value, with the default being to include no ALT value (which would result in a failure to validate)
Regrets: Charles Oppermann, Ian Jacobs
BK modelling on PAGL would be good.
WAC: There are three docs.
JT: We can have the two.
KB: We could include techniques in checkpoints document
CMN: We didn't have a decision on this before. Major reason for separation is to keep Guidelines to manageable size.
BK: Agree
KB: Don't disagree (at this stage)
JT: 2 important points. Need for manageable size, need for reader to go to different documents - various guidelines, etc.
CMN: We could incorporate a lot of it in techniques.
JT: we have then a large GL document.
CMN: We could start with a single document and see
BK: Or start with a double doc and see
KB: Looking at these things in hardcopy makes references difficult.
PROPOSED: keep one doc for now.
KB: Like specific techniques to be stated explicitly
JT: will be done
WL: can be generated from a script.
RESOLVED: for now, keep a single document with guidelines checkpoints and techniques
Ian's first proposal - agreed
Daniel's proposal.
BK: Do we want to ask them to verify markup?
WL: I'll be in that
KB: validation is a different issue
JT: this is about automatically creating markup
JR: replace produce by automatically
CMN: My assumption is that Ian's reasoning was that it was covered by standard markup, but it isn't in fact
JR: We could change the word produce
JT: Here we are being explicit about automatically generated markup.
KB: something like 'when automatically generating markup for the user, produce accessible markup'
?? does it matter whether it is for the user?
CMN: I'd like to leave this as is, and expand on reasoning in techniques
KB: leave in, but re-word
JT: 'do not automatically generate inaccessible markup'
CMN: I don't think we need to cover auto-generated markup
JT: This is different - this is markup not generated by the author.
WL: 2.4 and 2.4.2 are functionally identical
JT: This is the checkpoint
KB: switch 2.4.2 and 2.4.1
RESOLVED: switch 2.4.2 and 2.4.1
CMN: Do we add auto-generated into wording?
RESOLVED: Add 'auto-generated into wording of 2.4.2 'do not produce inaccessible markup'
JT These are separate things, and need to be separated
WL: withdraw proposal
JT: We need to talk about the overall process. This is about having very clearly defined checkpoints. We should add user-configurability to schedules early.
CMN: keep user-configurability as a guideline, move it up the order
RESOLVED: Move user-configurability up the guideline order
CMN: 2.5.2 and 2.5.9 are equivalent.
JR: 2.5.2 was a technique
CMN: 2.5.8 and 2.5.9 should be merged, optherwise can be misleading
JT: 2.5.8 and 2.5.9 should be merged, 2.5.2 into techniques
RESOLVED: merge checkpoints 2.5.8 and 2.5.9, and add examples as techniques.
RESOLVED: move 2.5.2 to technique
JT: 2.5.3 to techniques.
RESOLVED: move 2.5.3 to technique
JT: We need to keep an eye on the checkpoints..
WL: We'd better involve someone with the problems
JT: What's there came from people with the problem. We may need to broaden.
CMN: I am trying stuff like Jaws + Amaya. Amaya makes good examples, without breaching w3c vendor-neutrality, and they are incorporating accessibility
WL: people can also use pieces out of it
JT: Any other issues?
CMN: interfaces - let UA WG sort it out then incorporate it here
JT: This is covered under reference to User Agent
CMN: I would like to see it covered as an explicit guideline.
JT: there are a lot of things we could cover explicitly - what do we draw in?
WL: There are areas in an authoring tool which are a User Agent
JT: Intro says various types of rules apply. Then there are things specific to Authoring tools, which are all that is covered explicitly here. Otherwise we open a Pandora's box
CMN: I think we should fish into the Pandora's box.
JT: It was resolved to only put in things which are unique to Authoring Tools. So CMN is proposing to reopen that resolution.
General discussion.
RESOLVED Put it to the list to see if we need another before the face to face meeting.
Last Modified 9 February 1999 by Charles McCathieNevile