WAI AU Teleconference - 23 June 1999

Definitions

CMN There are some redundant definitions for alternative content. Proposal is a single definition for alternative content that steals from WCAG.

IJ I'm for it.

WL Will the word content come under scrutiny?

JT Yes.

/* DB joins

Resolved: Collapse these into single definition for guidelines document.

Removing checkpoint 4.3

CMN This is now redundant with 1.3

JT This was here because we had nothing to allow editing of everything

WC Change 1.3 to "display and edit" rather than display an editable"

GR I agree

CMN Me too

WC This includes structure too

CMN They are in 1.4 and 1.5

Resolved: 1.3 to read "allow the author to display and edit all ..." and remove 4.3

Splitting checkpoint 5.1

IJ This sounded like a lot of information - they seem to be separate ideas

GR Higlight the most accessible solution sounds like a technique

WL Yes.

IJ the word visible is unnecessary

DB We are saying that the features which produce the most accessible content are the most obvious?

GR for example, colour changes are most obviously done through style sheet rather than hard coding

JT Or for creating image map, the first option will be client side not server side.

DB My gut reaction is getting deep into telling people how to design applications.

CMN Propose second sentence to become technique

IJ Make it an example in the checkpoint

WL The stuff from the long example (image editors, sent by CMN) relevant should go in here.

CMN Basically the second sentence is taken out of the checkpoint

JT And change "visible" to "obvious"

DB I am not sure always how to make something the most obvious.

JT In most cases there are very few choices

CMN For example, in creating columns, you could do it by CSS as a default, and offer an option to do it by tables instead

/* KB joins

IJ So what if you divide it into two pieces - make sure it is easily initiated, and make sure that the most accessible comes first

CMN The first part is covered by 5.2. The concern is what happens when there are equally obvious options - does the tools pass?

DB That's one part of it. I'm also not sure that we should have this guideline, but if we have it then we should be sure that tools which are accessible and good will meet it.

WL The purpose is to promote the use of accessible solutions when they are available

DB So in an alpabetical list, do we have to bring things out of order?

JT Things are usually given by functionality.

CMN As a way further we could change the checkpoint as proposed, and note as an issue that we need to further investigate whether this is really implementable

Resolved: Second sentence to be dropped from main checkpoint text, "visible" to be changed to "obvious"

Copy organisation section from WCAG

IJ in Web content guidelines definition of checkpoints, techniques, guidelines was not as useful as an explanation of what we have there already.

CMN I think it is a very good idea.

IJ For example in the techniques document we should be able to explain that there are techniques by checkpoint and some that are by idea.

WL The definitions to large extent are defined by the current intro paragrapgh to the section

JT There is a confusion about whether techniques need to be implemented. Does it cover that?

IJ Yes. It explains that conformance is about checkpoints, and the techniques stuff is a separate document.

WL I like it

JT Are we losing the point that guidelines are principles, checkpoints are checkable, and techniques are suggestions?

IJ WCAG shuffled some of that to introduction

CMN I think we should make that crystal clear in this section

IJ That is already done in the status section. I have no objection to tailoring it.

Resolved: replace section 1.2 with WCAG section "how the guidelines are organised", tailored to fit and clarify status of techniques

Abstract, Introduction and Scope

IJ Scope of these Guidelines didn't say what I expected. I propose covering all the stuff in a single section.

CMN I agree with the proposal. The current Scope section doesn't cover as much as the Introduction, but is more or les redundant with the introduction. The issue of whether an image editor velongs is noted - better discussed next week since people haven't had chance to catch up to the list.

JT There is value in having a specific scope section for people to look at - the introduction tends to be prose, and the Scope section is easily bulleted.

IJ You can cover it in the abstract. I think the definition of a tool belongs in deifintions

JT We could discuss the title. Where do you think this disucssion should go?

IJ We should mention it in the abstract, explore it in the introduction, and define it in the definitions. The intended audience doesn't belong with the definition of tools.

JT We agree that the intro needs reworking.

IJ The user agent and web content guidelines begin with an intro to accessibility issues, for people who have never encountered accessibility issues. This document may not need that.

Action IJ: Propose an introduction which uses WCAG text, our intro and our scope section.

IJ Do we prefer haveing a tool defined in the intro?

CMN in the intro have a brief editorial explanation of what we mean, and have it defined in the definitions section.

Configurability as a goal

GR I would like to see 'by default' added to goal 2.

CMN Having not liked the "by default" when I first looked at it, I agree with Gregory that it should be clarified that we want accessible content produced by default.