Team Contact: Charles McCathieNevile (CMN)
Kynn Bartlett (KB)
Gregory Rosmaita (GR)
William Loughborough (WL)
Judy Brewer (JB)
B. K. DeLong (BKD)
Sylvain Galineau (SG)
Ian Jacobs (IJ)
Daniel Dardailler (DD)
Mark Day (MD)
Acronyms:
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
inline.
CMN: My strong opinion that should be two documents.
Could keep as one document for working with the material together.
JT: Propose two documents:
(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
problems.)
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.
Resolved:
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.
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.
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.
MD: I think this needs to be addressed on a case-by-base basis.
JT: If we go into these in detail, we'll find deficiencies in WCGL.
Opinions:
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:
Resolved:
IJ: Please also signal other WGs when information is more appropriately handled there.
/* Mark Day leaves */
/* Mark Day extension: 30576 */
/* Sandra Ferolito 35334 */
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:
JR: For example:
DD: I want two guidelines:
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:
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:
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:]
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.
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
Define User and Author
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.
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
(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
discussion
DD: Should be P3 checkpoint
KB: At most
WL, JT checkpoint
new order 2.1, 2.2/3 3.1 2.5, 2.4 including 3.7 as checkpoint, 3.5, 2.6
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
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.
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
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
3.1.1
2.6.2 +and links
2.2: we should add XML.
*/
1.a) 2.2/2.3 merger:
"Support all accessibility features that have been defined for the markup language(s) supported by the tool."
CMN: I'd like to make the W3C guidelines (first bullet) a separate 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.
CMN:
IJ: I can see two bits to this:
/* Break, BK leaves */
[2.2.3 turned into a guidelines]
DD: Is 2.2.3 user interface? (Part of 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.)
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".
Proposed:
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.
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.)
2 Ensure that content produced by the tool is accessible merge with 3.0
(Old guideline titles provided for reference:
)
2.1 Generate standard markup
Checkpoints:
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]
2.2.1:
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
Checkpoints:
2.6.1: [Priority 1]
Prompt the author to provide alternative content e.g. captions, descriptive video
2.6.2
Prompt the author for all missing structural information e.g. Table scope, form information
2.6.3
Offer prewritten alternative content for all multimedia files packaged with the authoring tool.
2.6.4
Alt-text registry prewritten and incremental
2.6.5
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.
Techniques
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.
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
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?
CMN/WL Yes
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.
JB: should be both...
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
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.
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.
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:
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.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.
/* 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.
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.
KB: Propose changing "inaccessible markup" to "inaccessible content".
Provide methods of checking and correcting inaccessible content.
Checkpoints.
for 2.7
/* 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.
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.
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.
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.
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 */
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).
Checkpoints:
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.
Proposed CMN: The default configuration should promote accessibility.
Include alerts for (WCGL) priority 1 checkpoints in the default configuration.
CMN:
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.
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 */
Intro: "The issues surrounding accessibility are often unknown to Web authors. Help and documentation should explain accessibility problems and examples of solutions."
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):
/* Break 15:30 - 16:00 */
elucidate the requirements. If the document can't stand up to such scrutiny, there is a problem.
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:
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).
Constraints:
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.
JB: Possible conflict with PAGL WG on 22 March.
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
JB OK
/* 17:30 Meeting Closed */