W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 26 January 1999

Details

Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca

Date: 26 January 1999

Time: 3pm - 4pm Boston time (2000Z - 2100Z)

Phone number: Longfellow Bridge, +1 (617) 252 1038


Agenda

Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WD-WAI-AUTOOLS-19990112. Where proposals are still current, but were based on old drafts, numbering given here reflects that of the current document.

Specific suggestions:

Proposed by Daniel Dardailler - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0000.html

Proposed by Ian Jacobs - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0028.html:

Proposed by Charles McCathieNevile - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0027.html:

Demote 2.8 (offer text site map) to two techniques/checkpoints - one in sectin 2 and one in section 3 and http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0009.html:

Define Accessible markup as 'Markup which conforms to the W3C Page Author Guidelines [ref]'

and http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0057.html:

Add 'allow author to correct inaccessible markup' to 2.3 (Identify inaccessible markup)

Proposed by Wendy Chisholm - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0002.html:

Proposed by William Loughborough - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0052.html:

Promote 4.1, 4.2, 4.3 to priority 1 status.

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 Charles McCathieNevile - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0056.html:

Instead of removing one of (identical) checkpoints 2.5.5 and 2.5.6 differentiate them so that one refers to audio, one to video.


Attendance

Present:

Regrets:

Absent:


Action Items and Resolutions


Minutes

JT: Charter clarification - do we need to do anything about people rejoining the list.

JB: No, but it is possible to remove members wo are not participating. Alternatively, establish list of members in good standing, and allow the list to stay public. This is probable EO approach

JB: Is this going to go to TR this week?

JT: Planned to. Agenda changes to be inlcuded if they are uncontroversial.

JB: OK. I'll listen along then. Publishing questions - should Nancy Scicchia be on editors list

JT: No real need.

Never remove exisiting structure

JR: Content is also important.

CMN: About ensuring that tools do not destroy markup.

JT: This is about several things - simplify and generalise from conversion tools to anything. Could have two Guidelines - one about not removing content, and one 'produce accessible markup'

IJ: Can we have these two?

JT: We have the first already - we can put in a checkpoint for conversion tools in 2.4

IJ: Why specific checkpoint?

JT: Good point. Rationale for conversion tools is to remind people

CMN: We should follow Daniel's suggestion modified - don't modify structure without notifying the author.

JT: There are examples where mark-up is changeed that do nothing to accessibility - would be annoying

*resolved do as Daniel says

*resolved - remove priorities from Guidelines

Do we have Checkpoints and techniques?

JT: We had both.

CMN: I collapsed tose out in editing, but included note to put them in.

JT: Propose priorities on checkpoints only.

JR: Example?

JT: message to list, 12 Jan. The checkpoints can be ticked off on a list.

*resolved - checkpoints and techniques, priorities attached to checkpoints.

JT: We listed them as checkpoint.

IJ: Preferred to Imperative?

JR: Better declarative

IJ: Needs to be consistent. Imperative allows us to tell developers what to do. It may be harping on semantics issue that is unimportant.

JT: Is consistency between guidelines important?

JB: Yeah, but needs to be internally consistent more

*resolved - use imperative

*resolved - delete rationales from checkpoints

Split site maps into two techniques, one in content area, one in UI

JT: In content area is very minor. Mostly covered. Initially intended for accessible UI, since major tools used fundamentally graphic map. 4.2 should refer to "tags" not elements. We could merge the two together in a guideline.

CMN: Site map in content could happily be a technique under 2.4

JR: There is an idea about integrating site maps within section 3.

*resolved - collapse 4.3 into an expanded 4.2, and explicitly mention tags.

*resolved - add technique under 2.4 for site maps (in the fullness of time)

Accessible Markup- define as 'Markup which conforms to the W3C Page Author Guidelines'

IJ: Is that a conformance staement?

CMN: No, but it is a definition of an oft-used term

JB: I don't think the definition makes sense. There is no specific conformance statement in the PAGL.

JT: We cannot replicate the whole PAGL here. We need to define the dependency on PAGL

JB: I'm not sure that the statement expresses the dependency sufficiently.

JB: Needs more levels.

IJ: PAGL are written with the author in mind. It is written in terms of what the author has to do

CMN: The requirements are the same whether it is a person or a program doing it. There may need to be multiple levels - and the assumption is based on a conformance statement or test for PAGL

JB: There are a number of subjective assessments to be made according to the PAGL. Gregg or Wendy would be good people to ask. If they're happy, I'm happy.

*resolved - ask Gregg/Wendy (chair/editor of PAGL) about it.

JB leaves - 3:40

*resolved - add allow author to correct inaccessible markup to 2.3

*resolved - use must/should/may language

Guiding principles:

JT: these are philiosophy statements

CMN: The sound-bite?

JR: Can see them going into short introductions.

JT: I see an advantage in having a soundbite. Maybe we want to add an introduction to each section

IJ: We need to kinds of Intro - a 'how to use the guidelines'

JT: We have that - section 1

IJ: Not big enough

JT: Can be expanded

IJ: Could be longer introductions in sections

JT: keep the soundbites and add introductions?

CMN: I'd be inclined to do that

JT: It gives a 'quick intro' to the section.

IJ: We can try it. It gets hard to distinguish guideline, section heading, principles, rationales - may reduce effectiveness. Section headings are already soundbites.

CMN: take 'em out - we can see how they work by coming back to this draft.

IJ: The ideas are good - is this the most effective place to have them?

JT: What's the difference betweeen a guiding principle, a section heading, and a guideline. This is the philosophy statement

CMN: Guiding principle is more of a rationale

IJ: Too many sound bites in a row. Can we use prose - say it in more words, and more comprehensively.

JT: Hesitant to leave them out now, because we might lose them for ever.

JT Proposed - add prose introduction, keep guiding principle?

JR: Don't like having 2 guiding principles

*resolved - incorporate Guiding principles into Introduction

P1 for 4.1, 4.2, 4.3

CMN: I think this refers to current 3.1, 3.2, 3.3??

JT: Those are currently P1.

Techniques:

IJ: what is 'or a properties field'?

JT: Attribute?

JR: I think it is attribute.

CMN: We are about time - produce new draft with Guideline changes, deal with Techniques on list / next telecon.

*deferred - Techniques/Checkpoints discussions, to list then next call.

JT: Next call 2 weeks. Should we review time for calls?

*action Jutta - review time for calls.


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 20 January 1999 by Charles McCathieNevile