W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 15 September 1999

Details

Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>

Date: Wednesday 15 September 1999

Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)

Phone number: Tobin Bridge, +1 (617) 252 7000


Agenda

The Latest Draft is the last call draft, dated 3 Septmeber, available at http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903.


Attendance

Regrets:


Action Items and Resolutions


Minutes

IJ: Did I have a proposal for restructuring the techniques?

GR: I prefer our structure becuase it has less indirection. One of Wendy's critiques was that there is little to distinguish the documents. I suggest putting a big header for the techniques

IJ: Why the WCAG techniques ended up the way they did: We had designed the guidelines and techniques to provide two different slices of information. Her initial thought about techniques was to do what Authoring Tool Guidelines does. But in WCAG we felt that it was handy to be able to deal with things by topics. Some of the presentation is by language (HTML, CSS, etc) rather than by checkpoints/guidelines. Once there is a difference between structures you need a map - we found by experience. There is not a one to one mapping, there is a many to many mapping between checkpoints and techniques

GR: One of the big problems is that the techniques are numbered, but not in a way consistent with the WCAG guidelines. That causes confusion.

CMN: I find that really difficult to use.

GR: is there an accesskey to the map?

IJ The first thing is a list of checkpoints, and if you select them you go back to the map where the checkpoint is listed

GR The navigation takes some time to get used to.

IJ Some people don't know WCAG has a techniques document. But I don't thnk that is a structure issue. Then some people get scared away because they land in teh techniques map and don't know where they are.

GR I would prefer something simpler. In most of the AU techniques there is a DT for a checkpoint, then an empty DD. Under that there is a UL. Putting "techniques for ..." in the DD would be handy.

CMN I like the fact that you go to techniques direct from checkpoints. I like having the ability to have topic-based sets of techniques (for example our techniques for a guideline, or sample implementations). I would like to cross-reference the topic sections, and sample implementations

IJ Can you link from a checkpoint back to the guidelines document?

CMN Should be able to

GR Could put a link in the DD header for the checkpoint list.

DB When this is final will wee have a checklist of checkpoints?

IJ Charles and I talked about it - that is pretty easy to add.

DB Being able to show people the requirements at a glance is handy. Even with WCAG there is a lot of extra stuff in teh checklist

JT A quicktips-type document would be good, too

IJ The current structure may be good for AU but I am not convinced that we should use it in WCAG.

CMN I think it is good for AU, so I would like to maintain it with necessary improvements

GR I would like to have next/previous/table of contents links at the end of each guideline.

IJ That means that I am already at the next one by the time I call for it.

CMN I'v never used them. It surprises me that I haven't used the contents button

GR That's because you use the back button

IJ So you could leave them out, and get people to rely on the back button?

GR I found that they have been useful, and people have asked for them in AU.

IJ It would be nice to have them all the same...

Action GR: propose something for navigation buttons, as in WCAG.

JT Are people happy with the present structure?

IJ I have other comments, but I am happy for now with the global structure. Basically I wanted more prose, rather than just bullet points

CMN I agreed. Some extra prose would be nice - anyone want an action item?

IJ Wcag is designed in part to be read top to bottom as well as by direct access. This is difficult to read top to bottom becuase there are so many bulleted lists.

JT Should techniques be clustered, related to each other, ???

IJ Well you don't want to follow the WCAG model of clustering, you want to make this prose rather than lists. I don't think this will stop recommednation, it would just make things nicer. In User Agent we are in the same position - we have some prose but mostly just list of points.

Resolved: We would like people to volunteer expanded prose for techniques.

JR Charles, when you mentioned diagram I haven't seen any figures in recommednations.

IJ In WCAG there are 2 figures. In most specifications there are lots of them. WCAG is probably lacking - we could do with more.

CMN Are people happy with Ian's proposal to remove techniques from 1.2, since it is a reference?

Resolved: No techniques for 1.2

UA dependencies

CMN I think the idea was to list what UA needed from AU, but this list is what we need from UA.

GR There is general confusion in groups about what they are supposed to be doing for a last call.

JT The dependency list is useful for us - we will need to review UA in last call, and need to know those things.

IJ UA had to deal with dependencies from Web Content. That's useful.

CMN They are going to examine it, but my impression is that they don't have many requirements on us (since we defer most of the relevant things to WCAG)


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 $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile