WAI AU Teleconference - 4 August 1999

KB e should define a term for documentation to be explicit about what we meant.

JT Yes, but the wortd documentation wasn't good because people think about it as meaning paper.

Resolved: We want a term for documentation, and a definition.

KB The important thing is to note that we are talking about the various types of documentation, not just the help file

JT But in some cases the stress is on teh specific electronic stuff

KB Right, and sometimes not.

KB I left 3 checkpoints alone. Wanted to suggest that if the doc is in html it complies with WCAG. Is this the right place for that?

CMN I'd say we should have it here as a technique, and maybe not just restricted to HTML...

KB New technique for tutorials - we haven't touched on them yet ut should.

CMN Should that go in the definition? (as well as examples)

KB Yes. Included in proposal - want to include technique regarding that. I proposed moving a few to 7.2.

Resolved: Adopt new techniques and moved techniques to 7.2 as per Kynn's proposal

KB New technique - It is important to document it's compliance and level (for the sake of users). And include w3c standards - specifications, in documentation, and include tutorial on checking for accessibility problems.

CMN Like "how to use the tool as it does guideline 6"

GR, CMN Sounds Good

KB I say link to or provide URIs (and list them...) Does anyone have objections to providing a list like that or should we refer to a list of resources?

CMN Within the techniques we do it already. Basically we just have to make sure that we are not collecting broken links.

KB Right. Is there a WAI list of documents.

CMN Not at the moment.

JT This may be a good action item for the CG group...

Action JT: Ask Coord group about this.

Resolved: Adopt Kynn's modifications to 7.2

KB I don't think we should require triple-A conformance - it might be unreasonable as written

CMN That's only a technique. If it is reasonable for everyone then we should make it a checkpoint

JT Someone might look at this and dismiss it because it is not possible for them to get to triple-A

JR We might want to suggest being at the same level of conformance as the program

KB The program may provide different levels of compliance. We should remove the mention of compliance level. A preferred way to do something like right justify would be style sheets, but there might be other ways and they should be able to docuyment those so long as they conform to single A. Propose new technique 'clearly label as inaccessible examples which include inaccessible authoring'.

JT That contradicts the checkpoint itself.

GR What about 'clearly label conformance level of any examples'.

KB I don't have a problem with that but it doens't sound like a technique...

GR I find it hard to believe that a manufacturer will mark an example as inaccessible.

KB I'm OK with that because it gets across the point. Part of the reason for the technique is to go along with the previous technique. If they show you a capabiility that is a bad idea they should make that clearer.

CMN I think we need to change the checkpoint, not just the techniques.

KB For example, if they have an accessibility-unfriendly method they should docuyment it, and that isn't allowed in the current checkpoint. Maybe we should re-examine this

GR A lot of these things are addressed in 2 and 3.

KB But we don't say 'only implement accessible practices'.

CMN The argument is more subtle - there are some things that are neither good nort bad practices except in usage scenarios

KB I see the need for something like this...

GR Doesn't the first technique in 7.4 address the concern?

CMN No it doesn't

KB It isn't a requirement anywhere.

JR Maybe what we should do is to say don't use inaccessible examples to explain authoring tasks - if the user asks how to make text blacker on the screen you wouldn't want to give them way out

WC Can't we just say 'make examples as accessible as possible'

GR I'm going to fight for this...

KB So how do you show people how to use the B element...

WC You don't need t odocument that. What it will look like can be created by using style sheets.

CMN There are 2 concerns - don't teach people bad habits, but we also need to leave this implementable.

JT Right - we still need to have the flexibility that we have

Resolved: Drop triple-A from 7.3 technique 1.

Action CMN: Propose way to deal with this checkpoint and address the two concerns

KB Second technique for 7.4 might belong in 7.3. Prposed new technique - take a broad view of accessibility practices - example don't talk about alt as being only for blind people, but for all users not using images. And "avoid using a 'handicapped icon' to give the impression that accessibility is only beneficial for disabled users

JT Should we include among these techniques a list of curb-cut advantages?

CMN Yes

KB Yes.

Action JR: Find old list of these.

CMN CAST might have something to say about not using the wheelchair logo...

KB Right. I don't know that everyonew should be modelling that particular behaviour. My opinion may be less important than others...

JT Bobby is a targetted tool, not just an authoring tool

CMN I am happy to put it in there

JT The WGBH Universal access icon might be good.

JR section 3.B.2 of first public working draft has list of access benefits that are widely helpful

Resolved: Reinstate those as technique for this checkpoint, and adopt Kynn's proposed techniques.

Action CMN: Ask CAST their opinion on the matter of using disability-specific icons

CMN JB might also have an opinion. I don't think is dangerously setting the cat into the pigeons (without having thought about it)

Checkpoint 1.3

GR Basically this arose from discussion of the checkpoint on 7 july teleconference. Just checking current draft, which has changed it a bit. My proposal was 'allow the author to display and edit the properties', and 'allow the author to display a non-visual equivalent - also P1.

JT That raises the two things we are trying to get at. I agree that it was/is confusing.

KB What do you mean by non-visual

GR non-grpahical

JR Is that the ability to change editing views?

GR No. If I am doing an access check, I need a placeholder for un"alt-texted' images

JR That's a browser

CMN I would suggest that it is in fact covered by 1.1 - I think it does not need to be in there

JT Although it is an important principle I don't think it is covered in the real world.

GR Yeah - I'm not sure that non-visual equivalent is appropriate.

Action GR: Re-propose this, with techniques, in non-media-specific language

JT Is a simple solution to say 'display an accessible equivalent of each element object property?

CMN That would do it for me.

JT We could give examples within that

GR So we are talking about splitting it to make the two things explicit - displaying everything, and being able to edit everything.

Resolved: Split 1.3 into two checkpoints to make it clearer - one for display and one for editing

Guideline 5

GR Proposed change of order in checkpoints - should list the P1 first.

CMN We had talked about doing that except in a specific case - I can do that now if we want.

Resolved: swap order of 5.1 and 5.2. In following draft, checkpoints will be ordered by priority unless people say not to.

GR I think 5.1 is in fact a P1.2

CMN I swing back and forwards on this one

JT By including the among this becomes less onerous, anbd can be done...

CMN The question is whether it is essential, or just important. It can't be decided on how hard it is, only how important the outcome is. It is at least important - is it more?

IJ I agree with that, but in practise you have to make sure that you have written it to be implementable.

JT This is a primary guideline. Why would it not be essential.

CMN I'm not sure

JT I think it is essential that they are among

CMN I'll buy that.

Resolved: Change 5.1 to a priority 1.

CMN So do we still want to change the order

JR Yes.

GR Umm

CMN Might as well for the moment.

Checkpoint 6.4

Propopsed by GR 'When the tool encounters markup that it does not recognise, inform the author. The tool should not remove markup without author's consent'

JT CMN made a counter proposal: Allow the author to override removal of unrecognised markup. Notes 1: the author may have imported accessibility markup not recognised by the tool. 2: This need not be a default option.

Checkpoint 4.2

CMN From my experience, this can be split across 4.1, 6.1 and 6.3.

JT I agree with that.

Resolved: Remove 4.2 - techniques to be distributed among 4.1, 6.1 and 6.3