W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 9 February 1999

Details

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


Agenda

Check for instant consensus

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.

Review of Latest Draft

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.

Specific suggestions:

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)


Attendance

Regrets: Charles Oppermann, Ian Jacobs


Action Items and Resolutions


Minutes

Do we have a separate techniques document? What are the definitions of each.

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

Instant Consensus?

Ian's first proposal - agreed

Daniel's proposal.

Delete 2.4.2 - do not produce inaccessible markup

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'

Merge 2.3.1, 2.3.2, 2.3.3

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

Add to 2.5.9

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

Other business

JT: 2.5.3 to techniques.

RESOLVED: move 2.5.3 to technique

JT: We need to keep an eye on the checkpoints..

Section 4

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.

Meeting time?

RESOLVED Put it to the list to see if we need another before the face to face 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 9 February 1999 by Charles McCathieNevile