WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus
Date: Wednesday 8 March 2000
Time: 4:00pm - 5:30pm Boston time (1900Z - 2030Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the Recommendation dated 3 February, available at http://www.w3.org/TR/2000/REC-ATAG10-20000203. The latest techniques draft is dated 8 March, available at http://www.w3.org/WAI/AU/WD-ATAG10-TECHS-20000308
MK is representing Allaire.
JT How have you found the guidelines
MK I think they are a lot clearer than before. THe techniques are important to make clear how to implement the guidelines.
JT A big question is from a developer's perspective what would you like in a techniques document
MK Practical points. Especially in the user interface of the tool itself.
/* WL joins.
WL Phone line problems.
/* GR joins.
/* Marjolein drops out and rejoins.
CMN We have a new document. Please send images with alt and longdesc.
WL / MK this is slow to download
MK It is 40 pages printed. I notice that som images are jpgs - not the most efficient format.
Action JR: make screenshots into .gifs
MK There are two images that are png objects. Can they be presented as inline.
Action CMN: check out the objects.
GR Similar problem making graphic pages - object doesn't work. This is the type of testing people need to do and recycle the information.
JT Can we create the document so someone can obtain an image-free version
CMN One possibility is to link to screenshots rather than include them inline.
JT Would that be helpful
MK I think it would be helpful. The images add to the weight of the document. But they help. Maybe we could provide two versions.
Action CMN: look into providing the document in two versions.
CMN Should we be linking to the document-type things rather than including them inline?
JT Could we have a link to cut-down versions?
GR They are dependencies - it would also make it easier to readjust if WCAG changes
JT It is fairly repetitive as well.
MK To have one page for each of the checkpoints - for example for 3.1 there are a few pages of checkpoints, and I got lost.
JT The nesting is not clear.
WL 3.2 is even bigger
MK Putting in a seperate document for each checkpoint would be better, but also prefix checkpoints to make it clear where they come from.
CMN It is probably also possible to combine 3.1 and 3.2 techniques
JT That is a move away from the structure we agreed on.
MK If you are going to put them in a seperate document I would prefer one for each checkpoint
WL What kind of detail do you want in responses.
CMN Send typos to the list. General impressions are useful.
WL For who is this intended?
JT Developers who are going to implement guidelines
CMN I would like to have a test set that describes what to do in order to test conformance, based on functions of a tool. For example: Inserting image - can you add alt, can you add longdesc, does it ask for them, does help explain twhat they are, does it check whether there is alternative, etc.
GR Right. Makes conformance evaluations quicker
JR Not in front of the developer, in front of the Author. Developer will have to refer to WCAG
GR Right. But we want to find out what tools do well and badly. This ends up being market research.
CMN In general are we moving in the right direction here?
/* Yes.
JT In looking at the present document, we want to go through the action items we had set out - there are a number of pieces missing.
PJ The templates are a lot more complex than I have seen. But I haven't sent them in - I need to clean them up a bit more. I thought it would be done last week, but I am hoping for Friday.
CMN I would like to send the templates to WCAG and ER for review.
JT I have discussed that in CG - we will do so.
CMN having them reasonably anonymised I think is important.
WL And disclaimered.
JT These will act as examples, but people can in fact take them and use them
GR Since they are going to be seen as examples of source and renderable documents, if there are mailto: URI's in there they can be live and we can link them to the AU mailing list.
JT Jan, do you have more stuff you are working on?
JR I am working on finishing up the piece that is in there already. I don't think it should be stuck into the middle, but maybe linked out of the techniques.
JT Having it linked from several of the checkpoints.
CMN In order to get this up for a TR draft we need to send this as an IG review by Friday.
JT I don't think we are ready for that - we should do a bit more work on it first. But I think doing some research on what developers would like to see will be helpful
MK An example. Under Guideline 7 - input device independence. Providing keyboard access to all functions is very general. Can we give more practical examples of how to do that.
JT In reading that guideline 7 did you look at the references? Most of the specifics are in other documents.
MK I am aware that guideline 7 is where our product is behind - to solve this we need to come up with more concrete examples.
PJ I was going to suggest that the IBM software guideines generalise these techniques, and give specific examples that could be pasted into the techniques
CMN I am wary of having this in the document - there can be a lot of stuff
MK I would prefer links
JT Should we have links to specific things from each of those techniques
PJ Sometimes these things move around.
MK is there a way t check the links?
PJ I was going to suggest that it might be useful to paste in the principles
JT The principles are there.
PJ I meant a level deeper than that - for example make sure you use the system settings for the operating system.
Action PJ: Propose text for keyboard accessibility.
JT How do you feel about the relative bits that have started out.
CMN My concern in linking out is that people won't read the references
JT I wonder if there is some way we can make it clear that this is a seperate piece.
CMN I think the example is the ERT document. We should add it like that
JT WL, where do you see your piece in the document?
WL I don't. I will work on it, but it is a broadside. Maybe it is an EO piece.
JT Can we have some examples out of HomeSite
CMN Sure. There are plenty of places we can get examples from.
MK I could provide screenshots - I have the very latest version, just tell me
Action GR: Make some suggestions for Marjolein.
Action MK: Take some screenshots and send to JR.
Resolved: We will not send this to IG - the milestone will slip.
JT There has been exchange on the list. It would be good to have suggested implementations and actual samples. In discussing the guidelines I keep getting asked what does this mean for my tool? I had suggested some more specific criteria - maybe like the tests you are talking about. Ian objected to the idea of "sub-checkpoints".
CMN This strikes me as a conversation that will take some time.
PJ I am in the same boat as Ian, but I really like the idea of the categories - what to do for graphics, etc.
CMN We can generate slices of the document.
PJ What is not clear is whether a particular technique will actually meet the checkpoint
GR It would be helpful to be able to clarify whether a technique will in fact meet a checkpoint.
CMN We could have a joint meeting with ERT in Amsterdam on Friday 12 May. Can people from this group make it?
MK, GR, CMN, JT, JR perhaps, PJ doesn't know if he is going to Amsterdam.
Resolved: We would like to have a joint meeting with ERT in Amsterdam if possible.
Action CMN: Liaise with ERT to try and organise this if possible.
CMN I think we want more evaluations - they are useful. It would be good to have a process for asking for formal review of reviews by developers
PJ There are places like webreview.com that do reviews - maybe we could ask them to do reviews. Anyone have any contacts?
JT We are doing some reviews - we can feed material in as it happens.
GR EO were discussing reviews - the question is what if a company takes exception? The American Foundation for the Blind asks companies for feedback.
CMN I think the reviews are useful, but I don't want to avoid publishing in case someone doesn't like it - evaluation and criticism is a common activity everywhere except police states, but developers can often provide further information, or even make imporvements.
JT It is important to be reasonably objective about a tool
MK A reviewer might miss something - the manufacturer can point them out.
Resolved: We will send reviews to developers for comment.
Last Modified $Date: 2000/11/08 08:13:13 $