WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: Wednesday 19 May 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990506.
/* discussion of how to deal with large-scale changes and proposals for change.
JT There are strong opinions on having it at either end, and general agreement (from face to face meeting) that it should not be in the middle.
EH First is fine
JA Front and centre
JT Phill Jenkin's argument posted today is that laerting the reader to the issue is already done in abstract, intro, etc.
EH My preference is to do the review and distillation of accessibility guidelines to principles which could be ranked. If that work on the user interface were done appropriately it may warrant its own section
JT It presently has its own section
EH I think it warrants that. And its own priority definition.
CMN I think this belongs at the beginning - this is one of several guidelines that really refer to external documents and we only include it here for the sake of completeness. All the other ones that refer to external documents are at the beginning
JR I agree - external references suit together at the beginning
IJ Why not have this in UA guidelines?
JT On Sunday agreed to create a complete set of requirements from other guidelines, include anything that is not covered as checkpoints and all the rest of the list
/* EH on Phill's action item - was he going to prioritise the list? JT To come up with a complete list. EH There are different uses of the word accessible, which can cause problems in relative references.
/* Dick Brown joins
Resolved: Put the guideline at the beginning, but note the position is an open issue.
IJ Would like to propose a W3C note which can be used by User Agent Guidelines
Action IJ and CMN: Look at producing a note which can be used like this, and then offer it to User Agent group
EH Could you also look at this for prioritising?
CMN We will do
Action IJ: Take proposal to User Agent group
JT There are checkpoints where the priority is based on the priority in the Web Content accesible Guidelines - for example prompting for alternative content. Two proposals for dealing with it:
EH My apporach was to separate them out. I only separated the ones where it wsa most critical. My suggestion is to indicate in the main document that it is a variable priority and provide a link to a portion which expands out the checkpoint into constituent parts.
CMN I would proposse to do the Priority R bit, and in techniques to list the checkpoints we import and their priority
JR I propose to do it in the document, and break it up, which also allows us to remap priorities for this document.
JT Three options:
JR Proposal one means that you can easily re-map priorities, and makes it clear in the checkpoint prioritires what needs to be done for conformance.
EH An advantage of that is that it makes it flexible, explicit, and easier to measure conformance. If we do it and it looks big we can look again.
JA In Web Content they have relative priorities, which are defined explicitly within the checkpoint, for example WCAG checkpoint priority 1.
JT That is kind of a third proposal - one checkpoint with phrasing for multiple priority
IJ What is the condition?
CMN Generally, reference to the Web Content Guidelines, for example it is P2 to prompt for P2 information
CMN Propose we go with multiple checkpoints in the same document.
EH Second that.
JA Agree.
Resolved: To split checkpoints where there are multiple priorities (IJ dissenting)
EH It should have the lettering
JR I agree - it may be confusing.
CMN It is tricky within the single week lifespan
JT It looks like one checkpoint, but has wording to make it clear.
IJ The work to be avoided (if we do it) is to tweak the scripts. It is necessary if we want to have the lettering, or we have to do a lot of messy hand-cutting. I don't think we should do that in one week.
IJ It isn't confusing to me as it is with some kind of priority R, especially if it is generic.
JT The concern raised is that we would be rnumbering things dramatically.
CMN I will look at the possibility of stabilising the numbering
JT Which checkpoints have that relative ranking?
IJ It might be more useful to be explicit about what parts of each guideline is meant. So in a definition of relative priority we refer explicitly to WCAG.
CMN That is the proposal we just rejected
IJ It may be a hybrid solution. If we are going to do that I would go back to the R rating
CMN 2.2.1, 2.2.2, 2.2.3 (Web content accessibility guidelines), 2.6.1, 2.6.3 (check and help correct accessibility problems), are definitely. 2.3.1, 2.3.2 probably are too (prompting for information)
JT In 2.2.2 we can only use relative priority for Web Content
EH Separate out Web Content guidelines from other documents.
JA We have addressed Web content in 2.2.2 and 2.2.3. I propose we leave 2.2.1 and have split for 2.2.2 and 2.2.3
DB 2.2.1 Implement all accessible authoring practices. If we are generating HTML, isn't Alt text included, and doesn't that cover prompting etc?
JT 2.2.1 not be relative, 2.2.2 and 2.2.3 be relative?
Resolved: 2.2.2 and 2.2.3 are relative
2.3.1 and 2.3.2 Prompting for alternative content and structural information
Resolved: 2.3.1 and 2.3.2 ar relative
JT 2.4 is not a candidate. 2.5 - do not remove accessibility content is not a relative
JR We may want to make it clear that this is not relative
CMN There will only be one checkpoint here, so it should be clear.
DB Can you give me an example?
CMN In RTF, if you have headings, and they are translated to font information, you are losing structural information.
2.6.1 - check and alert accessibility problems. (we don't have relative priorities for validity)
EH Why validity?
CMN Validity is an accessibility problem - it is unknown how to deal with invalid documents
JT Is there a proposal to remove the word validity?
EH Proposes remove the word validity
JA If we are going to remove validity we need to put it into the introduction, with an explanation of why.
Resolved: 2.6.1 is a relative checkpoint. Remove validity and add sentence to intro explaining why
JT 2.6.2 is not relative
JA There may be a problem with that - the first technique is to allow users to control prompting/alerts based on priority
JT This relates to question of disabling P1 alerting. An open issue.
Resolved: 2.6.3 is relative. Remove word validity from checkpoint
IJ 2.6.4 - does this refer to other checkpoints, or other documents?
JT This refers to checking for problems - identified problems and which have been repaired
EH I have other problems with this.
CMN the "make the tool accesible" guideline may have relative priorities, but we should defer until we have got a proposal on the table.
EH I propose adding a relative priority checkpoint after 3.1.1 - for authoring tools that use a web or weblike interface conform to the single-A double-A or triple-A conformance
CMN I suggest that you wait for the proposal on what will happen to section 3 and then put a proposal based on the revised version.
JT Propose CMN and I post priority wording for the relative priorities to the list.
EH Should we refer to conformance levels rather than priority levels?
CMN Yes, we will do that.
IJ User Agent guidelines do not have the same type of conformance statement.
Action IJ: Take issue of conformance to User Agent group.
JT Should the author be able to completely disable alerting for P1
DB Turning off is a timing thing - finding out never is implied by the option of timing.
JT A variant is to specify the default or shipped setting for alerts and prompts.
CMN I think we should allow disabling, but I think maybe we should have a default setting checkpoint
DB I agree. I think making the default turning it on is the way to go.
EH I agree
IJ Comment. In user agent guidelines we need to review user agent guidelines in light of Web Content Accessibility.
CMN It is a charter requirement for participation in this group to be familiar with WCAG. Good comment anyway
JT I think the way we have structured the document means there will be no effect on the checkpoints, but there will on the techniques.
JT Next teleconference we will have proposals for accessiblity of authoring tool. Hope for a good turnout - there will be a few issues to get through... See you then.
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile