W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 19 May 1999

Details

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


Agenda (draft)

Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990506.


Attendance

Regrets


Action Items and Resolutions


Minutes

/* discussion of how to deal with large-scale changes and proposals for change.

Position of "make the tool accessible guideline".

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

Relative prioirities

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:

  1. Create multiple checkpoints with distinct priorities for relevant checkpoints
  2. Create a priority R which defines the relative nature

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:

  1. Divide each checkpoint with relative priority into three checkpoints
  2. Have a category R, and spell out the exact interpretation within the techniques for each checkpoint

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.


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