W3C Authoring Tool Guidelines WG Meeting:

1 March 1999


Agenda: http://www.w3.org/WAI/AU/agenda-au-Mar99

Agenda 1) Structure and Scope (8:30)

Note: Clarification: author means user of the tool.

user means client browser user

How many documents?

JB: One normative form of a document: HTML (on the Web).

Paper copies are at own risk.

JB: Techniques documents are harder to stabilize. A good

reason to separate the documents physically. They evolve more often over time.

CMN: Normative v. Informative content. If there is a big block

of informative topics (techniques), would be easier to grasp if separated cleanly.

KB: Will our techniques evolve a lot over time?

Our techniques are more like broad implementation suggestions. Think they help more when read with checkpoints.

JB: What's going to be in the techniques? Currently one

(very informative) sample section.

JT: The AU Guidelines differ from UA and WC. These are

guidelines to other guidelines.

GR: Provide a third, integrated document with techniques


CMN: My strong opinion that should be two documents.

Could keep as one document for working with the material together.

JT: Propose two documents:

  1. Guidelines
  2. Guidelines + Techniques

(No separate techniques document).

JB: Example of technique content?

JT: See 3.2.

(Note: 3.2 in 26 Feb doc is scrambled.
There are other sections with little

CMN: Should provide a detailed help file. But difficult to integrate if large in size.

JR: Difficult to provide a help file with no context about how it would be presented, in which tool.

CMN: Can provide Amaya's interface. A separate document would allow us to do this.

JT: Could be part of an appendix or separate document.

Note: A technique is a suggested implementation.

Not required (for conformance). Illustrative.

JB: Given that, I lean strongly towards extracting the techniques into a separate document. Note: People don't want to read documents that are too large.


  1. Normative guidelines document
  2. Annotated guidelines document

JB: Are there other sections of the document that are scrambled?

JT: Yes, I think a number of them.

Action Ian and Charles: Review source document to find out why sections are scrambled.

Agenda 2) How to refer to other documents (e.g.,guidelines)? By reference? By inclusion? (e.g.,. Section 4)

JB: We need to separate how we address non-W3C and W3C documents. (Also, don't refer to Trace guidelines since will be covered by W3C documents). For external sources, need specific references as for other standards.

JT: Could use w3c covering these in a reference doc

JB: No, that won't all happen.

JT: We are in a quandary then, since we need a large amount of detail to deal with platforms

CMN: This is the sort of thing that I would put into a techniques document, because it is not an exhaustive list, there is no control over external documents

WL: Although there may be no W3C spec for making accessible software, this could lead the process of creating the necesary information.

JB: These guidelines could (or should) provide basic reference to necessary user interface features.

DD: UA Guidelines should address the user interface issues and requirements.

JB: But AU Guidelines must address authoring tool-specific issues (e.g., keyboard support for authoring functions).

JT: Must be careful that readers understand what must be done to produce an accessible authoring tool (and clarify that some of this information does not appear in the AU Guidelines).

BKD: Implementors need a comprehensive document to tell them what to do.

CMN: I'm not convinced that an authoring tool is a user agent. Most good ones are, however. Therefore, I don't think that UA Guidelines automatically cover authoring tools. We need to convey principles, but can't cover everything.

DD: I agree with CMN - give guidelines with pointers to platform-specific solutions. Where do the pointers lie? I'd like them to be outside of these documents. At WAI Web site?

CMN: To refer to existing resources in sections 2 and 4, propose including some informative prose giving principles. And have strong references to actual documents.

JB: (To MD): What would have been most useful to (Lotus) R5 developers a year ago?

MD: I don't know that there's any "right" solution here. It's a real issue: developers want to be told a single document to which they should conform. But they don't want the Boston phone book on their desk either.

JB: What is more likely to result in an accessible product?

MK: The will to build an accessible product.

IJ: Quoting or referencing must be done on a case-by-case basis. Include when very short or very important. Always reference.

JB: After this is largely finished, the WG should test usability of the document with some developers.

JT: When we quote an incomplete source, ensure sufficient caveats.

Agenda 3) If we find that there's a critical point that belongs in another document, what does this WG do? How to resolve dependencies on other WGs?

CMN: E.g., including DTDs in documents. Shouldn't this be part of WCGL?

JR: We shouldn't include things outside our scope. We should follow process.

JB: Note that WCGL went to last call last week.

CMN: Our first priority should be to take to the appropriate WG. Where not possible or dependency not recognized, we should include it in some way in the AUGL where considered critical. And include a Note in the spec explaining proper location for information.

IJ: Note that the WC WG continues to live on and will manage an errata page for the WCGL. This would be an appropriate place for information even after Rec.


  1. Signal dependencies to appropriate groups
  2. Ensure follow-up by them (e.g., in spec or errata sheet)
  3. Include solutions in AUGL and remove when addressed in other WGs.

MD: I think this needs to be addressed on a case-by-base basis.

Agenda 4) Should we address access issues for languages other than HTML: XML, SMIL, MathML, schemas, ...

JT: If we go into these in detail, we'll find deficiencies in WCGL.


  1. The AUGL should be general enough to cover all these languages.
  2. Follow WCGL
  3. We should explicitly discuss other standards and fill in where WCGL inadequate.

KB: What is WCGL's position on the other languages?

JT: (Citing Wendy Chisholm). Their hope is that the WCGL are general enough. In future versions, will be more specific on other languages.

WL: We should keep the AU Guidelines general enough to serve as a model to us (the WG).

KB: The guidelines should be general. The techniques

document should deal primarily with HTML. We can add techniques in sync with other groups as usage of the other languages is understood.

CMN: We should have general guidelines:

  1. WCGL have attempted to address this and I'd be surprised if there are massive shortcomings.
  2. We will need specifics for other languages. But we should not wait to hear how languages used - we need to consider accessibility ahead of the curve.


  1. Guidelines and checkpoints will be general enough to cover emerging standards.
  2. Guidelines will inherit access discussions from WCGL/UAGL.
  3. Techniques may cover emerging technologies and expand on them when not covered by WCGL or UAGL.

IJ: Please also signal other WGs when information is more appropriately handled there.

/* Mark Day leaves */
/* Mark Day extension: 30576 */
/* Sandra Ferolito 35334 */

Agenda 5) Should author-generated and automatically generated markup be considered separately?

DD: They're the same.

JB: Can we agree on what the difference is? There may be a difference, but it may not be what's written in the proposal (or the accompanying solution).

KB: Replace "automatically" with "transparently"? In Composer, for example, lots of solutions chosen without the author knowing the source code structure. Other cases involve the author knowing exactly the markup.

JB: Lotus Notes may be in the middle of the two worlds.

SG: Conversion (to HTML) is another issue.

DD: Everything comes from the author's action. We should combine the two topics since the guidelines document will be simpler, shorter, flatter.

JT: Explict author choices of markup differ from transparent tool choices. The tool can encourage author to adopt solutions in the former case, not the latter.

DD: A valid distinction, but not worth complicating the guidelines.

BKD: E.g., MS uses ??.Dreamweaver will use BLOCKQUOTE to indent. Fusion will use invisible GIFs.

IJ: Elicit the distinction once to indicate when the tool should promote accessibility, give help, etc.

BKD: Have a guideline that says that accessible solutions should be chosen. Might list solutions
in techniques doc.

CMN: Some cdheckpoints might apply more strongly to an edit-as-you-go tool than to a conversion tool. I don't think the distinction is important enough to justify different techniques. Techniques may vary according to flavor of tool being used.

JR: Propose distinguishing "support accessible markup" and "ensure accessible markup".

DD: Support of markup is always followed by creation of markup. No need to distinguish.

KB: I support JR's point and don't think the two should be collapsed. There's a difference between support for and promotion of. There's a three-part argument:

  1. Support standard markup
  2. Support accessibility features of standard markup
  3. Use those features.

JR: For example:

  1. Support HTML 3.2
  2. Support "alt"
  3. Ensure meaningful "alt" text.

DD: I want two guidelines:

  1. Support valid markup.
  2. Create accessible markup.

JB: Number of guidelines less important than completeness/appropriateness of checkpoints since conformance related to checkpoints.

KB: Need to say more than "support for" (i.e., something's in the document tree). Perhaps 2.2 needs to be written in a more concrete way that would allow 2.3 to be eliminated. Otherwise, e.g., an editor development team might skip the section thinking that HTML/CSS support is sufficient.

JT: Proposed: Rewrite 2.2/2.3 intro text and verify that checkpoints in (reduced) 2.2 are sufficient.

JT: Seems 2.1 needs clarification: We don't mean to imply that the entire standard be supported.
Thus the words "according to the standard."

CMN: I'm not clear on this. HTML 4.0 specification doesn't talk about conformance to subsets.

IJ: No subsets in HTML 4.0 to conform to. Find a way to say that for those parts covered, the accessibility features be supported.

JT: Can't assume that all of the HTML 4.0 spec is handled by the authoring too.

CMN: If you use a non-W3C DOCTPYE, you must use one that doesn't stop accessibility features.

/* Break */

/* 11:05 */

JT: So what is the meaning of Guideline 2.1?

DD: Why do we need a fallback checkpoint? (i.e., if you don't support W3C standards, ensure accessibility).

CMN: Guideline should say:

  1. Generate markup that conforms to a W3C spec
  2. Use W3C specs where possible
  3. In some cases, not possible or desirable. In those cases (say, a music markup language), ...

DD: In case #3, we don't care. Don't specify guidelines for the future.

CMN: An authoring tool should be able to conforim to the AUGL without generating W3C markup.

DD: It's not helpful to say "Be accessible even if you don't do any W3C things".

KB: People put Word and PDF documents on the Web anyway. Should we tell them that for this type of document, they should still consider accessibility (but outside of scope of these guidelines).

KB: Support doesn't mean authors can simply enter elements and attributes. It's possible to generate a valid page while not supporting HTML 4.0. We say support but don't say what we mean by support. Propose dropping the word "support". Find more specific terms and clarifying what is meant.

CMN: We must allow authoring tools to extend the available languages but where a spec exists, it must be used.

KB: If we say that your generated HTML must be to a W3C DTD, developers will balk when they hit that checkpoint. Perhaps we need to allow author choice, even if that means giving them the choice to produce non-standard markup. Don't ask developers to limit marketability of their tool.

IJ: a)Phrase checkpoints to allow for non W3C where inapplicable.
b)You can't do much else. Where is "inaccessible" defined?

CMN: Do we need to define accessible or inaccessible.

IJ: Warning about this. See WCGL for principles but no definition of accessibility.

DD: I think we need to address versioning and future versions, but possibly not in Guidelines document. In practice, people will be using extensions. So be it. Allow author override of validity checker, but require that a (W3C) validity checker be available and strongly encourage its use.

/* Charles minutes for last few minutes */

From CMN saying that the extended 2.1 allows for increased accesiblity.

IJ: It is outside of the scope to do anything except say "you should use a W3C spec where possible". To extend the requirement is outside of our scope, since we can't define "inaccessibility".

CMN: We assume that the WCGL define accessible. We use inaccessible and need to define it anyway.

IJ: WCGL do not define accessible. They talk about some ways to achieve it.

DD: It could easily be phrased to define it

IJ: I don't think you need to define it to prduce an accessible.

CMN: I use a working definition of if it doesn't conform to WCGL it is pretty damn likely to be inaccessible

IJ: Only pretty damn likely

DD: I think I agree that we could go with Ian and keep to one checkpoint in 2.1, but we do need to provide for some versioning. There will be people extending DTD, and tools may then allow over-riding of the validation, but they should validate against HTML.

/* Ian leaves 11.35, Charles minutes here */

KB: I validated HWG website, and it got knocked back because it included longdesc, etc. It is important somewhere that we support future versions. Maybe this belongs in "do not remove accessibility markup". It needs to be adaptable, but that allows publication of a DTD that would be different that they could update, but that's the trade-off we make. I think it is acceptable as a trade-off.

GR: Where there are extensions, we need to co-ordinate with the manufacturers - if Frontpage extends, their User Agent should match it.

JT: We are talking about validating the markup, which is within the purview of the Authoring Tool

JB: Many users will be told "you have to use the highest level compliance", or something, so there would be a little alert to come up.

DD: Sometimes i think we should not allow anything we have not declared as a valid extension. Maybe HTML 5 will have added some even better accessibility features. How do we tell the reader that "this is new and valid"? We need to produce errata or new version to allow the extension

CMN: I don't think we should be stopping extension of the DTD, because that seriously stifles the usefulness of this document. We must also be able to innovate. We are not granitng a blank check - we have a strong restriction, although it is currently badly worded, that innovation must not destroy accessibility.

WL: We cannot restrict the freedom to innovate and we cannot impede accessibility. The best way is to restrict impeded accessibility

JR: Maybe we should say "you are out of conformance for six months

DD: We are producing best-practise guidelines, and we are saying what is good. Best practise is to use HTML 4.0. We have no way to check whether extension is accessible, so we shouldn't be giving our brand out. The risk is that people will drop the whole thing.

CMN: If we can't explain what accessibility is so other people ca figure it out themselves, then we ahve a really big selling problem - we are setting ourselves up as the high church interpreting the unknowable.

KB: We should provide the option to conform to W3C standards. You can allow others

DD: In the authoring tool they can have an extension, but checking is validated to HTML 4.0

WL: So a text editor could be conformant as an authoring tool.

JT: We seem to be agreeing on two things:

  1. 1) Where possible use W3C standards
  2. 2) When using other than W3C standards, do not interfere with accessiblity in W3C standards.

KB: Use W3c Standards (2.1.1) is a bit vague. Where possible is very vague - on one hand it is always possible to use HTML 4 for an HTML document, but where possible might mean I want to include this feature where possible in my extensions, which isn't in HTML 4.0, so I don't have t use HTML 4.0

DD: There is syntax invalidity - it must be syntactically valid so that it can be parsed. If we had a checkpoint saying check the validity against HTML 4 you can configure it to be valid, or you can just work in an environment which lets you extend.

JT: We want to say: Always use applicable W3C specifications

GR: Create content in accordance with W3C Recommendations

JT: This covers what we mean to say. Next, if you are going to extend it, ensure accessibility

WL: So is the next one about if W3C specifications are not applicable

JT: Right - if not applicable, you are extending - then do not interfere with accessible markup

KB: I'm not sure that it allows the user to use a non-W3C DTD

WL: As long as they extend W3C standards, rather than arbitrary ones.

KB: 2.2 needs to include not precluding accessibility. (as opposed to here)

JT: The merged 2.2/2.3 says if you are covering HTML (CSS, etc) incompletely, make sure you still cover all the access features. Here we are saying if you are extending, ensure you do not extend without all the access features.

KB: We could collapse all these things into one guideline

JT: Let's make sure we include all the points before we work out how to collapse the guidelines. So the next thing to say is: If you extend a specification, make sure that the extension does not interfere with accessibility of the non-extended content.

JB: How do we define accessibility?

SG: Provide an example

CMN: The frames example via email

KB: Seems that a subset and an extension fall under the same checkpoint

DD, CMN: right

JT: So: [3 proposed checkpoints:]

  1. 2.1.1 always use applicable W3C specifications
  2. 2.1.2 If you use an incomplete set make sure it includes the access related specifications
  3. 2.1.3 If you extend the specification amke sure that the extension does not interfere with accessibility of the non-extended content.

KB: 2.1.2 Always do X when Y is stronger than If Y then do X, so 2.1.2 Include all accessibility-related specifications when using a subset of W3C specifications

WL: We can easily define accessibility.

JT: We can easily define what is accessible within the W3C specifications, so that is the point we should agree on first

MD: You can just say 'don't extend if it interferes with accessibility'. The concern that I have with current phrasing is that it appears to allow extensions which are not accessible.

JT: So we could run with that. Process?

JB: Say "this is what we decided. Is it OK with you"

WL: 2.1.2 - we are already using the term accessibility, which meand we have defined it.

Resolved: New 2.1.3:

Extensions to W3C specifications must not reduce accessibility.

MD: Explains where we are meeting tomorrow - Training room I, Lotus Development Building. Sign on door says Lotus Presentation Center. If you need more lunch tomorrow, let me know.

GR: Last iteration should say not impairing access to th content of the document and the functionality

WL: Not reduce accessibility includes function and content

CMN: We should say that our definition of accessiblity includes access to both content and function.

WL: Wants an agenda addition - the Oppermann Objections

JB: I would like to be here during tht part of the meeting. I had a long conversation with Chuck, and I think the group does need to address the comments - I am not sure that he has made his case.

//lunch 12.30 - 13.30

JT - Revised Agenda: Go through 2,3,4 in order, discuss chuck's process stuff, presentation.

Define User and Author

RESOLVED adopt Kynns definitions

KB: Using Ensure is weak - make the actual verb the imperative. Word checkpoints more actively: So RESOLVED

RESOLVED Techniques after Checkpoints ASAP


Proposed text for introduction, which defines accessible content - provide some synopsis of what we mean.

Charles' and Wendy's proposals

DD: we should have a summary, but it should be short.

JT, KB: techniques?

DD: I don't think there should be a section 3 - it can be subsumed into the other two sections.

CMN: can this be dealt with in section 3?

DD: No, because it impacts the intro to gl 2

JT: I am happy to flatten it so long as we don't lose the checkpoints.

JR: 3 groups well.

DD: eg checkpoint 3.7.2 also fits under 2.4

JR: They are fuzzier

JT, DD: But that is not a problem.

CMN: I was against this, but I am not any more.

WL: Can we change content provided by the tool to tool output

DD: No, they have different meanings - output can be interpreted as screen output.

RESOLVED: Collapse 3 into 2 and 4

RESOLVED: Add 3 intro to 2 intro, along with some (5 line) definition of accessible, and a link to WCGL.

Order of guidelines 2.x and 3.x

DD: We want a guideline about standard markup..

JT: That is 2.1

DD: And something about having all accessibility specifications

JT: That is 2.2 - was 2.3 and 2.3

RESOLVED: Move 2.5 before 2.4

(was 2.4 - Identify, and allow the user to correct, inaccessible markup)

DD: Next should be 3.5 - allow user to configure checking

JR: Unless we merge them

DD: No, needs to stay separate

JT: So, order is check, correct configure

new order 2.1, 2.2+2.3, 2.5, 2.4, 3.5 so far

DD: Next put help and documentation before Alternative management

KB: 3.2 and 3.4 should be next to each other, or combined

JT: What happened to 3.1 - emphasise accessible authoring practices

JR: 3.7?

DD: 3.7 to checkpoint under identify and check

WL: Is it OK to have rationale with a checkpoint?

WL: 3.1 into 3.7

CMN: yes

KB, DD 3.1 should come after 2.3

DD: What's the difference between 3.1 and 2.2? Supporting in attributes, or help support, is all part of the same thing

JR: A lot of these could go into 2.2

JT: 2.2 would get pretty large. As Jan says, this is to do with a specific step

KB: move 3.1 after 2.2/3

new order 2.1, 2.2/3 3.1 2.5, 2.4, 3.5, 2.6

BK, DD: 3.7 could go into 2.4

KB: I don't like 3.7

JT: people think it is patronising

JR: doesn't patronise - authors don't read it

KB: This is a technique
CMN: I agree

JR: this is for the psychology - needs to be a checkpoint


DD: Should be P3 checkpoint

KB: At most

WL, JT checkpoint

RESOLVED 3.7 to checkpoint of 2.4, P3

new order 2.1, 2.2/3 3.1 2.5, 2.4 including 3.7 as checkpoint, 3.5, 2.6

DD: combine 3.2, 3.3, 3.4 in one guideline with all the checkpoints. - RESOLVED

new order 2.1, 2.2/3 3.1 2.5, 2.4, 3.5, 2.6, 3.2/3/4

is help included?

JT: no - it's different

DD: Yes, it is documentation

//IJ returns, 14:15

IJ Help is different to documentation

WL: You're both wrong!! (smile)

3.2/3/4: Promote Accessibility in help and documentation

KB: 3.6 and 3.1 could be merged.

JR, WL: Ummm..

KB: 3.1 and 3.6 both relate to how accessibility is included in document.

JT: Do we put 3.6 after 3.1?

JR: They should be sequential

WL: 3.6 is directed to manufacturer, 3.1 deals with the interface

JR,DD,JT,KB they both deal with the interface

RESOLVED: 3.6 to follow 3.1

IJ clarify 3.6 - lose word naturally

JT: But that's the point of the guideline

DD: integrate is to have it part of the program. Naturally means make it feel llike a part from design

WL: If you did it badly it would not be integrated

CMN: I am prepared to live with the extra word, to make it clear.

JR: Make 3.6.1 into the guideline - RESOLVED

new order 2.1, 2.2/3, 3.1, 3.6 (named as 3.6.1) 2.5, 2.4 incl 3.7 as a checkpoint, 3.5, 2.6, 3.2/3/4

KB: 2.6 is down a level of detail compared to the rest

JT: Alternative content is the most important accessiblity consideration - supporting ALT content is well on the way

CMN: It's great, as a P2

KB: Could it go after 2.2/3 and helps explain the idea of accessible markup

CMN: I'd be in that

RESOLVED: 2.6 after 2.2/3

new order 2.1, 2.2/3, 2.6, 3.1, 3.6 (named as 3.6.1), 2.5, 2.4 incl 3.7 as a checkpoint, 3.5, 3.2/3/4

TO discuss
checkpoint : integrate accessibility into checkpoints

/* Ian's minutes start here. */

/* Raised but not resolved

2.6.2 +and links
2.2: we should add XML.

Review of Daniel's and Kynn's comments in light of new section 2:

1.a) 2.2/2.3 merger:

"Support all accessibility features that have been defined for the markup language(s) supported by the tool."

Resolved: Change "Support all" to "Implement all".

CMN: I'd like to make the W3C guidelines (first bullet) a separate checkpoint.

Resolved: Add the following checkpoint:

"Conform to the Web Content Accessibility Guidelines" (No priority specified yet).

KB: 2.3.1 says "Don't produce inaccessible markup". I propose that this be merged with this new checkpoint (i.e., delete it in current state).

Proposed: Add intro text from 2.3 to 2.2.

KB: Introduction of 2.3 distinguishes auto-generated and author-generated. The text may favor too much the author generation.

Proposed by Ian: Make 2.2 limited to W3C languages and accessibility features (separate NOTES) for those languages. Therefore, change title of 2.2 to "Follow W3C accessibility guidelines"

/* Return to 2.1 */

DD: Proposed: Promote accessibility through extensions.

IJ: I think this will break interoperability. Shouldn't talk about extensions (let alone promote them) to W3C specs.


  1. If you are going to extend a DTD, you should do so with a published DTD. DD: Too hard for most authors. CMN: But not for authoring tool developers.
  2. When you extend a DTD, ensure that content or function is not lost to users without it.

IJ: I can see two bits to this:

  1. When you do something done by a W3C spec, be consistent with that spec.
  2. When you do something new, what do we say? What are the guidelines for doing something accessibly?

Resolved: Delete: 2.1.2.

/* Break, BK leaves */


  1. 2.1: Generate standard markup
  2. 2.2: Support accessibility features of W3C specifications

[2.2.3 turned into a guidelines]

DD: Is 2.2.3 user interface? (Part of 3.1?)

Duly noted that DD feels 2.2.3 belongs in 3.1.

IJ: May need to create a section on supporting alt text for all of those checkpoints. May be a more natural division than what is there now.

Proposed for 2.2: Ensure that templates for inserted markup conform to WCGL (e.g., frames, tables, etc.)

Guideline 2.6

CMN: I don't think you can move 2.3.3 to 2.6. You could strike all of 2.6 and move to 2.2. Because alt content for multimedia objects is such a massive problem, it seems to make sense to me to single it out (i.e., make it more visible). It's good to factor out descriptions for frequently repeated images. Borderline technique, therefore worth considering as a checkpoint.

KB: I get lost in 2.6.6. The wording is clumsy.

CMN: I think 2.6.2/3/4 are clearly covered by 2.2.3 and should be removed.

DD: All prompting should be on a configurable schedule. This should be defined once (for "prompt") and not repeated in checkpoints.

IJ: Propose a new guideline: "Prompt the user for missing alternative information" (based on 2.2.3) Keep all the 2.6 checkpoints related to prompting under this. Pre-written stuff as well.

JR: Need the functionality of the registry as a checkpoint here as well. A technique would be the registry.

IJ: 2.4.1 and 2.6.2 refer to schedule. And guideline 3.5. Proposal to move discussion of scheduling to definition of prompts and alerts. (Maybe include "on a configurable schedule" at first occurrence of "prompt".) Links from "prompt" and "alert" to their definitions.

Propose 2.6.1: delete "that complies with the WCAG".


  1. One guideline about managing alternative content. (2.6.1 modified/5/6).
  2. One guideline about prompting user for missing information. (2.6.2/3/4). Possibly more depending on importance of specific need.

IJ: Should all of the second guideline be shrunk down and pushed back to 2.2 since this is a reflection of the Web Content Accessibility Guidelines?

DD: No, leave here, but list all the pieces explicitly.

IJ: But people wanted to see multimedia explicitly. That's why these were made into checkpoints in the first place.

JB: We should list here.

GR: By doing this part right, we can have developers

integrate accessibility solutions at the same time they are doing other verifications. Developers shouldn't think about as something they do afterwards, but rather during. (Ensure that 3.6 relates this).

KB: Useful as a large section of the AU techniques document: annotation of WCGL (note: not techniques) aimed at tool authors. "This is how this part applies to you."

JT: This is how the AU guidelines started!!

DD: I think "prompting" should include "offering of prewritten content".

CMN: Getting missing content is one thing. Managing the alt content is another nightmare. This goes beyond the question of getting what's not there.

DD: This is a technique then.

KB: I agree with DD. I think all the management/prompting checkpoints should be put back together (under managing). We can emphasize the alt-text through the big example of section 5.

CMN: I'd buy the point that managing accessible content is a checkpoint.

KB: We're too hung up on how this should all be managed. An alt-text registry is a great idea, but perhaps we don't need tools to fill-in previously entered text. This is too close to a technique.

Resolved for (one) Guideline title:

Ensure that no accessibility information is missing.

(Subhead: If accessible markup or content is missing, prompt the user for it or offer pre-written descriptions, templates, etc.)

Resolved new structure at close of day: (numbering from feb 25 draft)

2 Ensure that content produced by the tool is accessible merge with 3.0

(Old guideline titles provided for reference:


Resolved checkpoints at close of day.

2.1 Generate standard markup


2.1.1 Use applicable W3C specifications.

2.1.2 Extensions to W3C specifications must not reduce accessibility.

 2.2 Support accessibility features of W3C Specifications

[intro to be wordsmithed]


Implement all accessibility features that have been defined for the markup language(s) supported by the tool.

2.2.2: Produce content that conforms to the W3C Web Content Guidelines

2.2.3 Make sure that templates to be inserted in the document comply with W3C Web Content Guidelines

2.6 Ensure that no accessibility information is missing

Intro: content, structure, offer, management


2.6.1: [Priority 1]

Prompt the author to provide alternative content e.g. captions, descriptive video


Prompt the author for all missing structural information e.g. Table scope, form information


Offer prewritten alternative content for all multimedia files packaged with the authoring tool.


Alt-text registry prewritten and incremental


Do not generate description text or insert place-holder text except human-authored description text when the meaning or function of the described object is known with certainty.


An extensive example is provided elsewhere in this document

Allow authors to make keyword searches of a description database (to simplify the task of finding relevant images).

Provide an author with the option of specifying alternate content, or electing to insert null alternate content. Default to an accessibility error such as no ALT attribute for images

Suggest pre-written descriptions as default text whenever one of the associated files is inserted into the author's document.

Allow authors to add objects and alternative content to a database.


Note. A new draft based on this resolved structure was produced, and distributed to members at the commencement of the meeting tuesday. All references to AUGL hereafter use the numbering of that 1 March Working Draft

Tuesday March 1

start 8.55

WL: less intro text would be good

action editors to write 2.3 intro covering content, structure, management

GR Not having section intros allows faster technical interpretation

WL: can these general principles go into abstract

IJ you need some intro to each set of checkpoints

CMN Charles Oppermann was keen to have more intro to checkpoints

WL It's in the abstract

IJ, no it isn't all there

JT Where should text now in 2.3 go?

DD should be shortened and kept

JR should professianlly written go into a checkpoint?

WL can the intro notes be distinguished from the checkpoints?

CMN already happens in the 'official (= online)' version

KB, JB arrive 8.55

section 2.4

DD: I woul like to merge 2.4 with either 2.2 or 2.5

WL: It is logical under 2.2

DD: Supporting things includes the emphasis on doing it right.

CMN: I agree with daniel

DD: It is a lower priority version of the same

IJ: Why would it go here?

CMN: Because providing encouragement is part of supporting the accessibility features

DD: It helps to reduce the number of guidelines

JT: We don't want to lose anything

WL: Discouraging bad practise is part of supporting accessible practise

JR: is it?


JR: You can provide technical support without encouraging.

CMN: Yes, but it doesn't split as far as a guideline

//little section of minutes from Ian

WL: Publishing differs from saving (don't interrupt saving, interrupt publishing).

KB: 2.5.2 seems like stating the obvious.

MD: Might be a plausible for leaving this in the document: common sense not widely distributed. Structured editing, for example - usability nightmare, but some people decided philosophically that this was a good thing. The situation with accessibility is analogous: not allowing saving an inaccessibility nightmare is a usability problem

//thanks Ian

MD: common sense ain't common. it is a good idea to have editors which wouldn't let you construct incorrect programs. this caused a serious reuseability problem. it is not the case that you have a better tool if you can't save an inaccessible document

DD: I want to keep this, but move it to configuration - there we should say that fundamental operation should be controlled. or maybe in the checking.

WL: I want to second what he said about innoculation. this illustrates that we are not proposing draconian measures to mess up the environment. at the same time there should be something i the language which emphasises why this should not be published. - your own space and public space are different

DD: They are not different

JB: In some casses a person gets a 95per cent finished document and publishes it. I don't think there is a difference

JT: we're going in circles. So we move this to checking or configuring.

Straw poll: checking? 4 configure? 4

JB: should be both...

RESOLVED: move checkpoint 2.5.2 into both 2.7 and 2.8

GR: "or postponed"? How is this different from asking if you want to save changes? There are times when something will pop up and honk at you.

KB I don't think a prompt is the same as 'postponing'.

MD I want to have the feature, but I want it to be configurable?


what do we mean by highest priority?

IJ are we talking about 2 different accessible solutions? Isn't it already a no-no to present inaccessible options

DD I thought this was more to ask for the alt text immediately, rather than hiding it. So maybe there shothis should split in two. Make accessible practise visible, and promote highest priority.

IJ are the specific practices which should be checkpoints eg when you insert an image get ALT text

BK maybe should be techniques

IJ Maybe, but there are some things which seem like techniques, but are so important that they need to be checkpoints. Most visible isn't clear

KB: Example: image editor - first dialog has height, width, filename, and then you need to click 'advanced' for Alt text

IJ: Yes, but the wording is still not verifiable

GR: Ensure that there is a place for accesible features on the main screen

BK rather than buried under dialogues or something

GR: Ensure that options presented include accessibility options

IJ: This sounds good - it is verifiable

JR you are assuming a dialogue box or something

IJ not yet.

GR: This can happen in anything.

JT: Should be one of the first things you see - should be at the top,

JB say 'prominently include aceesibility options.

CMN: Wherever options are presented, accessibility ones should be there

WL at the same level

IJ what does 'the same level mean'

GR: Means that these are base functionality features.

KB I don't see why this doesn't presently meet the criteria?

IJ I don't know what most visible means

JR: example: in frontpage you can use font, or CSS to change colours. in frontpage, the toolbar option uses font. to use CSS you have to go through a process.

IJ that is an example that doesn't apply, because one is inaccessible. Where there are a comparable set, you can order them. perhaps: Include both required and optional accessibility features in interface components.

JT: doesn't make a checkpoint

IJ needs wordsmiting.

JT this got at the emphasise and make it easy to do.

GR: i think it might be easier to make checkpoints for each of the three strands than trying to get this encapsulated.

JT 3 things: needs to be few steps. needs to be visible. needs to be at the top of the list of choices

ACTION kynn - rewrite this and send to list. Add default configuration.

GR: having 3 checkpoints makes it easier to get all the steps implemented.

IJ: between same semantics, choose the most accessible first

WL: does it say that I have to put alt before filename?

IJ: No. only deals with order where there are two ways to do the same task.

Guideline 2.6:

RESOLVED 2.6.1 goes

JR: 'these processes are hidden form the users view and may create inaccesible content' - same thing

IJ: and RTF is a markup language

BK suggest we rename the guideline itself. I see it as having to do with HTML produced by a conversion

JT: I think it is for anything that removes acessible structure

JB I thnk there are a few things where the name of the guideline doesn't match. I think we should talk about structure or content. There are 3 things. don't strip stuff out, don't add junk, and don't alter. should we look at specific examples?

WL 2.1.2 ends on wrong word

CMN I think 2.6.3 is the crux, and should be generalised boyend accessibility

KB: We could express this as positive

IJ generally i prefer positive

DD in this case I prefer negative - Never remove is stronger than Always preserve.

JR: maybe we should reword the intro to encompass changing and importing.

GR: do you want to cover both here Daniel?

DD I think we can cover both. Sylvain might have an example, because Domino translates on the fly from a lotus format - apparently the native format has accessibility info, but the conversion doesn't use it.

JT I think the guideline is clear and succinct, and there are lots of instances where ths happen. Can we express that in the introduction.

IJ 2.2 says do the right thing. 2.6 says 'don't do the wrong thing'. Can they be merged?

JT I think we need to be clear about this.

DD As much as i like less guideline, I like this guideline

JT I think we need to have a principle

KB I agree that we need it because this goes back to what is the problem? It addresses a big problem that a lot of editors have.

RESOLVED: change intro to cover the various bits

JT Should we change the checkpoints, to have Judy's don't add, don't strip, don't alter

GR: Should we include changing the DTD?

KB 2.6.3 sounds like it should tell you about that. Changing DTD is a structural change

GR: I don't think it would hurt ot explicitly state something like

CMN: I don't think we need to say don't add. DTD is in techniques

DD: don't strip is part of don't alter

KB How about changing a 3.2 DTD to a 4.0?

JB: Key is notification

KB: 2.6.2 - should preserve any markup because it might be necessary for accessibility but not recognised

DD: I think we need to understand these issues. If I create the perfect tool it does HTML 4.0. If I keep it for HTML 5.0, do I apply 2.6.2, or do I extend DTD?

KB: The problem is that we are identifying specific things and everything else can be removed

IJ we will have a set

KB we have a set for now, but next year it may not be complete.

JR: How about only removing structure you know is not for accessibility?

IJ: How do you know if it is not for accessibility? Where possible we should be able to refer to a common set of things.

JT: Clarification - this is not User Agent, and we have talked about what we mean by accessibility features, but Kynn's point is that if that changes, there are things that are not covered by this.

KB Even if it looks wrong, then it shouldn't touch it

DD: HTML 4.0 we changed the map content model. in HTML 5 it will be different - it will be better If I use HTML 5 model and validate on HTML 4, it won't validate. I know better, so I should have the last say.

JT: I don't want to have an editor stopped from removing junk I don't want.

KB: I am saying that it won't know what accessibility needs

BK: we shouldn't be encouraging changing markup - it is impssible to make an authoring tool that knows everything

IJ eg I write HTML 4, and your 3.2 tool strips out stuff editing it to validate it as 3.2. I wouldn't ask the HTML 3.2 tool to know about html 4.0

DD: I think the tool should validate - it modifies the markup to make it valid.

CNM: There are two ideas here:

  1. We don't want the tool to remove markup without asking.
  2. we do want a tool that takes crap and produces css plus html 4.0.

kynn's point is valid - we can't define the set of things a tool should not change. a tool should not change structure or markup representation without checking with the author.

KB: remove automated from 2.6.3 add to 2.6.2 to give 'never automatically remove or modify structure that is necessary for accessibility

CMN: we don't have an exhaustive set. we have 2.2 to cover accessibiltiy. So the need for this guideline is to talk about not making the changes under the hood - ask the user if they want to make them

JT: But the user may not know what are accessible changes

KB that's what context-sensitive help

GR: I don't have a problem tih doing this

JT are you assuming that all authors are going to know what are the access bits are, or that they are going to read all help

GR: I don't see that it is an either/or question

IJ: User Agents ignore what they don't recognise. Can we ask authoring tools to change this behaviour? We are asking them to change for the future, which is what is contrary to the way that forward-looking languages are developed.

JR: You make a good point. Problem is that many Tools ignore what they don't know. Maybe we should have a checkpoint which says ignore what you don't know.

IJ there are tools which we want, which can convert bad to good. The rest, to survive, need to ignore.

JR if you can have a bad to good then you can have a doesn't matter to doesn't matter

GR I thik it would collect all the unknown elements, and present you with a summary of changes

JR we are trying to use automation, not gathering stuff.

GR I as an author would prefer the information

JT so what is the default

DD - leave it in. Configure to fix broken stuff.

cmn - perhaps have a checkpoint - ignore what you don't understand.

that's an important part of this checkpoint, but we also ask that you

work to a valid dtd. Leaving in bad stuff is mutually exclusive with

a valid dtd.

JT: suggested by Kynn: rather than referring to content for accessibility, we say never remove content. We cannot defince the structure for accessibility, but we want to be able to improve accessiblity. You can prompt the user to say yea or nay, but that takes the emphasis from developer to user.

IJ with WCGL we had two sections - one big and one small. Here we have the same - I propose we should put them in a single section. We discussed the two topics in the intro to the section (see WCGL intro) and then we had the single run of contents.

DD I wanted that for WCGL but I don't want it here.

//Ian minutes from here:

11am Ian on notes.

Re: Guideline 2.6 continued

WL: Most of what we've been talking about is more in the realm of techniques than checkpoints.

IJ: Don't leave information up to reader when you can be specific. W3C Recs should not be ambiguous or leave open to interpretation when it's possible not to.

Resolved two checkpoints for 2.6:

  1. Don't remove markup that is known to promote accessibility.
  2. Don't remove unrecognized markup without alerting the author.

/* Discussion as to whether "a" is obvious/necessary */

Also: Summary of structural changes, formerly 2.6.3 is

a technique of how to alert the author.

Still required: list of techniques.

Guideline 2.7

DD: Delete Note in this section and refer to Guideline 2.8.

CMN: Proposed: Switch 2.8 and 2.7 [No.]

DD: Guideline 2.7 text: Provides ways of checking and

correcting all inaccessible markup

/* Can we talk about "inaccessible markup"? */

IJ: I think that it's difficult to say "inaccessible markup is not what's in the WCGL".

CMN: A rough definition is "what breaks the WCGL".

KB: Inaccessible markup includes at least that which breaks the WCGL.

Please note that the definition of "inaccessible markup" refers to a definition in the WCGL, which doesn't exist.

Action Ian: Redefine inaccessible markup. Link from instances of "inaccessible markup" to the definition.

KB: Propose changing "inaccessible markup" to "inaccessible content".

2.7 Resolved:

Provide methods of checking and correcting inaccessible content.


/* Reminder: definitions of prompt and alert include according to a configurable schedule */


DD: Checking without reporting is pointless. The two are bound together.

CMN: Proposes:
2.7.3 and 2.7.4 are subsumed by 2.7.1

DD: I'd like to see three checkpoints related to checking: asynchronous, synchronous (on demand), on open/save.

CMN: Any scheduling feels like a technique to me. The key is the alerting. The configuration guideline talks about the details of scheduling.

GR: "Provide a mechanism to alert the author."

DD: When is user-configuration.

CMN: Checking is partially configurable: on open and on save. Author also has the possibility of being alerted during edited. Perhaps open and save should not be negotiable.

MD: Everything is negotiable. Forcing alerts is the kind of thing that kills you in a review.

WL: Provide a hook so that the functionality of checking can be used in non-UI circumstances, namely programmatic control (in and out).

JT: You want to check at other moments than on save: you want unobtrusive notification. Correction is crucial to an authoring tool that promotes accessibility.

CMN: I'm not saying we don't do those things (they are covered by the author having a schedule). The issue is: is there a particular point when the document MUST be checked. My suggestion is that if so, this be a checkpoint.

DD: We discussed merging 2.7 and 2.8. Should we revisit that possibility?
Also, we need to refer to two kinds of alert (obtrusive, unobtrusive) from checkpoints.

KB: I don't like the idea that you MUST have something even if the user wants to turn them off. ** For 2.8, we need a guideline that says that the default configuration must promote accessibility. It should not be easy to turn off accessibility checking, but it should be possible.

JB: I am also uncomfortable with a phrase from earlier: "it doesn't matter how much of a sales problem it is". The author has to be able to configure the tool to different levels. Not everyone will be using tools in a compliant situation.

MD: Please note that a "checking" process may be time-consuming. If applied on every open or save, may be too time-consuming.

2.7.1 Resolved:

Check for accessibility and validity problems and alert the author of them on a configurable schedule.

Issue: Should 2.8 and 2.7 be merged?

KB: I think there are other configuration besides checking/alerting.

Resolved: Don't merge guidelines 2.7 and 2.8

DD: Two kinds of checking: valid HTML and accessible HTML. CMN: These are techniques of checkpoints discussed elsewhere. We can point to existing tools.


IJ: Proposed changing "know the details of the markup" to something based on the tool, not the author.

Proposed: Two checkpoints:
a) Assist correction
b) Don't require direct markup editing.

CMN: Doesn't a include b?

JT: We want assistance to resemble the authoring tool mode: when markup edited directly, assist that way. When manipulated through an interface, assist that way.

KB: Barrier to authors if we require them to know all the accessibility features of HTML, CSS, etc. They don't want to know the inner workings.

CMN: I'd like "a" only. Implementation of "b" allows product differentiation. These are therefore techniques, not checkpoint-level issues.

JR: I kind of agree. We can't assume that just because most of the tool is WYSIWYG, the access functionalities will be, too.

JT: Perhaps "a" only with a link to the checkpoint/guideline about "integrate naturally".

KB: I want more than "integrate naturally". I don't want to know the details. It's so important, it needs to be a checkpoint.

GR: The point is well-taken, but I think it should be a technique.

2.7.2 Resolved: (one checkpoint).

Assist authors in correcting accessibility and validity problems in a way consistent with the authoring interface.


IJ: Add "on a configurable schedule". Otherwise MS Bob will be telling me "Way to go!"

KB: I don't love this checkpoint. I think it's condescending. This would be a good technique for teaching people, but should not be the authoring tool's role to pat me on the back.

WL: The point is not to congratulate, but provide a status report.

CMN: I do use software that tells me how far I've gone.

IJ: What's the measure of your progress? Tool developers don't like to do look-aheads since costly to calculate (e.g., after edits). Are there status reports of spell-checking?

JR: There are binary ones in Word: no errors/some errors.

2.7.3 Resolved:

Provide summary information of document accessibility on a configurable schedule.

/* 12:30 - 13:30 Lunch */

/* Bruce Roberts (Lotus) joins the meeting */ /* Judy Brewer, Mark Day, B.K. leave */

Guideline 2.8: "Allow authors to configure accessibility mechanisms"

WL: Should this guideline appear earlier in the document?

DD: I don't think the order will matter that much since few guidelines in the end.

Also: Refer to earlier checkpoints that refer to configuration (e.g., of help files).



Resolved: Delete "for a given set of options". Also link "alert" to definitinon of alerts. DD: What about when printed?


Resolved: Delete the parenthetical expression.

2.8.3 Resolved: Delete

Proposed CMN: The default configuration should promote accessibility.

Resolved new checkpoint: [priority 1]

Include alerts for (WCGL) priority 1 checkpoints in the default configuration.

Don't restrict what can be done for configuration. There are more pieces to configuration than just accessibility.

KB: Browser should be configured out of the box to promote accessibility. Authors shouldn't have to change settings.

BR: Wording of new checkpoint fine to me.

Proposed checkpoint:

Fundmental operations such as saving, closing, and pasting should not be canceled or postponed due to he existence of accessibility problems.

JT: Judy felt we should keep this.

JR: Guideline 2.8 (being at the end of Section 2) is saying "We're not crazy; we don't want to make life for users or developers difficult."

DD: Move to intro text.

CMN: If it's necessary for accessibility, make it a checkpoint.

DD: What is the risk if you don't have this checkpoint? Who won't do it?

KB: This is not a checkpoint for accessibility. Move to intro of section 2. This is an instruction to the developer. This checkpoint doesn't increase or decrease product or markup accessibility.

GR: I agree: common sense, not a checkpoint. Belongs in abstract, or 2. intro, or 2.8 intro.


  1. Put in abstract
  2. Put in section 2 intro text.

Resolved new checkpoint:

Select accessible options in the default configuration of author preferences.

CMN: Propose moving 2.8 to 2.4 (and 2.5 combined). This would even make the document more readable. Does the look and feel include the default? Putting them in the same place makes it obvious they do.


/* Some editing done on section 2.7 */

Resolved 2.7 Checkpoints:

Guideline 2.9

Resolved 2.9: Promote accessibility in help and documentation.

Intro: "The issues surrounding accessibility are often unknown to Web authors. Help and documentation should explain accessibility problems and examples of solutions."

Resolved 2.9.1: delete


KB: 2.9.2 sounds like it could be a technique of a more general checkpoint along the lines of "Provide help for accessibility-related issues." 2.9.4 Too touchy-feely.

BR: In our product, the author is divorced from the document language. They access the features through the user interface. Don't talk about "document language" since too techy.

Summary of main checkpoints for this section (after which we'll choose checkpoints):

Resolved checkpoints (except for exact wording):

Resolved: Move checkpoints 2.9.2 - 2.9.8 to techniques:

/* Break 15:30 - 16:00 */

Resolved: For checkpoints that don't have established priorities, put "Priority X".

Review of discussion about Chuck's concerns

DD: To me, the requirements are close to the guidelines.

JB: To me, the requirement is the unmet need. They enumerate why things go wrong.

JB: Essential problem is that people put inaccessible documents on the Web. Break this down into:

  1. They are unaware.
  2. The tool removes accessible features
  3. The tool makes it difficult to get to accessible authoring practices. ...

These are met by the basic strategies of this document: alerts, prompts, configuration, etc.

JT: We have requirement lists in archives and older documents.

JB: Then it would be good to isolate and name (and verify it).

ACTION Jutta: Dig them up and ask questions about them on the list.

Conference call time


Sylvain: Any time but Wednesday

Proposals: Every other Monday, 15:30 - 17:00 ET.

Every other Wednesday, 15:30 - 17:00 ET.

IJ: Wednesday 16 - 17:30 better for me.

Resolved: Next teleconf: 8 March 15:30 - 17:00 ET.

JB: Possible conflict with PAGL WG on 22 March.

Section 3

Note earlier resolution: We will put intro text here that summarizes (tersely) both the software and user agent accessibility guidelines.

/* Jutta reads from 8 Feb 1999 email entitled

"Regarding Accessibility of Authoring Tools". Considered a kind of list of requirements for section 3.

3.1 Resolved: Ensure independence of authoring and publishing environments

/* Editor: Need to rewrite intro text to 3.1 */

One objection to 3.1 guideline wording: you can't force an authoring tool also to be a browser. Also, the intention isn't that you need to provide a WYSIWYG view.


(New checkpoints follow)

DD Proposed: Provide a structural view of the document. For example, you insert a frame but don't want to see the rendered frame - you want to know that a frame is being used.

CMN: You want to provide information about the structure of one or more documents (hinting at site map). You also want to provide information about included objects.

DD: I distinguish multimedia (with descriptions) and structural markup.

JT: Note that these checkpoints help satisfy the navigation requirement in an authoring environment.

GR: Needs to be author-configurable which information about document parts is available. Want to identify elements as you go.

DD: Techniques include: For images, file name. For tables, ...

DD: This is a textual description (voice, braille, screen reader).

Resolved: Allow the author to display a textual equivalent of content while editing.

DD: (Note that textual equivalent includes more than a longdesc or alt (e.g., can included file name).

GR: Does 3.2.2 or some variation belong in guideline 3.1?

JR: site map is used twice. Once for producing content. Once for working in the authoring environment

JT: therefore we need to rename the guidelines. There are, in 3.2, pieces which will never appear in the published content.

DD: it is one feature of interface that is common, often implemented by file management.

JT: one of the most popular wasa hyperbolic view which was completely inaccessible.

DD: proposed to flatten the structure of this section for the moment.

CMN: help / documentation must be accessible.

JT: it is in UA GL

JB must be here or it is ignored

GR must be reiterated

JB referred from the intro?

JT yes


/* 17:30 Meeting Closed */