WAI Authoring Tool Guidelines Working Group
AGENDA REVIEW
JT: put things in afternoon at the request of those joining us--evaluation topics, mainly
// CMN tries to get the agenda from the web, but has to rely on his cache //
JT: agenda review:
1. structure and minimum requirements for Wombat
2. sub-text and intro text
3. minimum requirements - post checkpoint text for each checkpoint - refer to MK's post of 18 June 2001
4. evaluation techniques
5. review of current evaluations
CMN: Graham Oliver (GO) will be calling in at 1:30pm local time, as will Phill Jenkins (PJ) and William Loughborough (WL)
JT: GO will be reviewing Lotus review he performed-is it available
CMN: published it to the web over the weekend
JT: additions to today's agenda?
JR: discussion of 4.1 and 4.2
JT: on agenda--discussion will be based on JR's posts to au list AGENDA ITEM 1: Structure of Document
JT: as move from ATAG 1.0 to Wombat, want to perfect structure of document so can move to 2.0 easily; opportunity to look at structure and come up with consistent structure
// CMN displays Wombat version of ATAG on projector //
CMN: go through issues one-by-one?
JT: want to start by reviewing existing structure; have GL itself in as brief a form as possible (Support accessible authoring practices); introductory text that introduces set of checkpoints--intended as motivational and explanatory text to clarify what fits into this category of checkpoints--no real pattern to explanatory/intro text; within checkpoints, have checkpoint itself, minimum statement an advanced statement, and references to related checkpoints
// CMN gets connected //
GB: who will be using ATAG?
JT: developers of authoring tools; will be used by policy makers, purchasers, and others, but primary audience is developer
CMN: rough guide: these GLs with list of checkpoints that relate to WCAG plus the things that authoring tool must do in order to be accessible to PWDs
JT: not sufficient for building a checker tool, but how an authoring tool can integrate checking into the look & feel of the tool
// CMN shows current techniques document //
JT: question this morning is, is this the structure we want to stick with? How do people feel about the abstract nature of the "at minimum" statements? Have we reached the right tone in regards the at minimum
CV: in relation to what?
CMN: the structure of the new document
JT: added recently "at minimum" and "advanced implementation" statement along with related checkpoints/guidelines; previously, didn't have much--just some notes and explanatory text
CMN: general principle of "at minimum" is fairly helpful; in discussion with developers, developerslike minimum; helpful to make minimum satisfaction explicit
MK: also helps to be more specific; not just "good idea--now what do I do?"
JT: that question should be answered by techniques
CMN: diff between reading GL and implementing it; ATAG small enough--explanatory material mostly in techniques, to which developerswill have to look
MK: access document with different views and in different details
JT: responsible for growing the doc--had a very short GL document and a very large techs document; wanted to give reviewers of ATAG a bit more info so didn't need to keep referring to techniques
JT: other objection -- with wide array of tools, there are so many diff implementations, shouldn't be too specific in GL, so as to allow developersto exercise judgment, creativity, etc. -- have we gone too far or not far enough?
GB: are techs proscriptive?
JT: no-GL is, with exception of "at minimum" which does set a proscriptive minimum; talk about functionalities author using tool would need; from author's perspective, this is functionality that should be there
CMN: bottom line--no matter what type of tool, minimum requirements are "what is required to perform task X"; techniques are suggestions and further discussion/clarification
JT: more complicated; don't have much to go by when doing complex evaluation
CMN: new techniques structure
// CMN illustrates //
CMN: techniques marked as "required" or "suggested"--basic idea is, if you do some things, you will meet checkpoint, if do others, may be good things to do, but don't satisfy checkpoint; need to ascertain if we have drawn delineations correctly
JT: required statements in Techniques make good candidates for further descriptions in GL itself
GJR: requirements in Techniques bothers me
JT: do we need an "at minimum with every checkpoint? JR: if don't then interpretation will be they don't know MK: helps structure
JT: so need minimum & advanced JR: advanced not always necessary due to variations in tools we are addressing
CMN: thought search checkpoint was very clear, but with at minimum and advanced implementation info, much much clearer; plus, as JR said, helps saleability of doc
JT: put in advanced so that people wouldn't stop just at minimum
JR: this checkpoint promotes/requires verbiage needs to be discussed;
JT: describe
JR: construct plays diff role in diff situation; what needs to be done; provides more context;
GJR: is bothered
CMN: in terms of requirements in techniques, idea isn't this is required in a normative sense, so need to sort between informative and normative; techniques informative--WG's opinion of what can meet checkpoint--if don't get to this level of functionality, haven't met checkpoint; point is to give guidance -- informative guide to what kind of techs need to be implemented
GB: isn't GL a description of policy and techs a "hint" or suggestion of how should be implemented; GL should be concise and general and abstract so rarely change; techniques should change and be updated often to reflect emerging technologies
GJR: I understand the point of reorganization, but am concerned about terminology
CV: use term "minimum requirement" -- why?
CMN: for specific example, 4.2 -- help author correct accessibility problems; one dev (MS) said, having info about how to correct in help section is enough; WG didn't think that was sufficient
CV: be explicit in checkpoint, then
JR: other GL documents rely on sub-text and requirements
GJR: (not minuted)
CMN: what happens--write things up reasonably briefly in 2 or 3 pieces with redundancy or write one long thing that says everything we are trying to say--better to have 2 or 3 statements that more or less say the same thing, than one monolithic thing
CV: rationale between dividing GL 5 & 6 -- seem to be one GL to me; so close together--one GL with 2 sets of checkpoints
CMN: most checkpoints are related to each other; most GLs closely related to one another;
JT: GL 6 breaks GL5 to some extent -- one is concerned with integration, the other is specific sections that address accessibility
JR: entire document could be summarized as "make sure that accessible content"
GJR: should be "make sure anyone can create accessible content"
MK: GL5 and GL6 fits different styles of working--better for end user of product
JR: GL3 a special case of other, broader GLs
MK: guidelines versus techniques -- ATAG is what product manager uses to evaluate where tool stands--basis for work orders; developers will use/rely on techniques
JR: part of my thinking--very minimums out of techniques and into GL
JT: one risk is that it binds the document temporarily--are we reaching the right abstractness
GJR: no
CMN: in some yes, in some, no--need to look at each minimum--how long do we want this to last? Five years? Six months?
MK: max lifetime should be 2 years at most
GB: what if tool doesn't do anything that the techniques say?
GJR: wrong approach -- shouldn't stick specific verbiage into -- blah blah blah
CMN: not entirely true--inherited structure from ATAG; need to throw stuff on wall to see how works; as for longevity, if rely on ATAG for 2 years, is that a significant risk--will we have broken things found? WG will be asked more specific questions; doing what we're doing if keep ATAG 1.0 intact; hasn't turned up a lot of howling errors--my goal is aim for document that lasts 5 years, which means that it probably won't live for more than 2 years; W3C process good at weeding out bad design; broad enough to cope with range of tools (illustrator, lotus notes, Amaya, video editors, online courseware, archival software, etc.) and durability of GL abstractions; functional requirements aren't such a problem--can point out in techniques how to satisfy for platform specific design; technique becomes--use OS conventions; if put in requirements about things tool has to do to a specific ML, then have problems; criterion for minimum--is this good in every case? If a case that this is a bad thing to do, this should be highlighted in techniques
GJR: problem is access to walls -- who's throwing, who's washing?
GJR: structure techniques descending order from this is best to this is ok, but watch out for, and this sucks but you can do it anyway?
// discussion of axes in techniques //
GJR: need better structure for techniques--hierarchy and headers
CMN: critical for a checkpoint, easy to do, platform specific stuff
JT: tentatively "at min" and "advanced" structure might work, so Wombat is a test of that structure; going back now to ascertain if worked and what further thoughts on structure we have
GB: example of necessary techniques for 4.1 -- what would be necessary?
JR: at minimum statement in Wombat [JR quotes proposal from AU list]; others don't agree that any automation is required;
CMN: why I want to get into specifics after break; techniques capture assumptions and M.O.s; GL has to be short enough for a project manager to read--if too long, won't bother with it--has happened in the past; need a short enough version that it passes that hurdle; in techniques, need a lot of verbiage--not clear and concise like checkpoint text
JT: GJR, do you have any thoughts on proposed structures of alternative ways of doing it
GJR::
JT: could put at minimum in techniques as first statement in techniques document;
JR: that does mean that you have to switch documents
MK: product manager will just read GL
JR: could say in top of checkpoint document that the subtext below checkpoint not part of document, but first technique provided for explanatory purposes only
CMN: would like not to do that; have biggest possible division between what is required by checkpoint and what is explanatory material; in techs, these are things we think you need to do, but this isn't the only way; if do this way, we believe you have satisfied the checkpoint; minimums needs to be actual requirement
GJR: suggesting a three tiered document
CMN: concrete proposal: based on GJR's comments:
GB: min requirement an interpretation of checkpoint -- what tool should do and what isn't sufficient
JT: more advanced should be paired with at minimums
CMN: suggesting that we break up narrative sub-text into point form chunks
JT: larger overview--retain 3 documents; move checklist to executive summary?
CMN: checklist should remain the checklist; Wombat checklist: listed by priority and includes sub-text
JT: intended just as a checklist
CMN: only has priority info and checkpoint text; propose that add ATAG introduction; page of narrative plus list of requirements
JT: different document than had previously
MK: not sure about that
JT: different intent; worries me that taking checklist and repurposing it to do something else
CMN: as I think about it, checklist is a thing that I look at a lot; read document 27,000 times, and I want to look up particular chapter and verse to find explanatory material; want to give people GL document--does that suffice? Is it the right level of document?
MK: as former PM, the at minimum are really important
JR: grab just GL text and GL intros and put those together as executive summary
JT: need further explicit structure in GL document and techniques document; top-level document--repurposing checklist? Extraction from current ATAG?
CMN: GL document and a techniques document enough to track; save
CV: need a Schema for document, not just XSLT
GB: if want to set priorities, write content first, build techniques, then think about implementation details
// 10:30 break //
JT: worry about executive document later after GL and Techniques
// Karl Dubost joins //
KD: Quality Assurance activity--help people build better guidelines and specifications, test suites, conformance evaluations, etc.;
JT: start with Guidelines document; in terms of structure of LG document, at the moment have:
JR: restatement of checkpoint, background, context
JT: do people agree with structure? Additions, subtractions, changes?
CMN: projecting an illustration of what we currently have; changing checkpoint sub-text so that at minimum, more advanced, rationale,
MK: start with rationale;
GB: why CP is important?
JT: rationale and/or context -- perhaps should be label for field
MK: still rationale -- keep it
// agreed -- keep rationale //
CMN: "se also" -- techniques and other related checkpoints
MK proposes: Checkpoint text, priority, rationale, at minimum, advanced, pointers
JT: how should they be written: at minimum are functional
CMN: at minimum and advanced should be functional and user orientated--what user will be able to do
MK: what, rather than how
JT: are each required or recommended for each checkpoint--in some checkpoints, rationale tends to be redundant
CMN: require and at minimum in each checkpoint; rationale and more advanced are shoulds; seems likely that will have more advanced and rationale for most checkpoint; if put techniques link into "see also" will have "see also" for each CP
GB: why "more advanced"
CMN: better implementation
JB : why not call it a suggestion?
CMN: further set of functionality that you might add
JT: purpose was to balance the "at minimum"--reason for more advanced was to encourage people to do more than minimum
MK: if can do this, would be really cool
GB: not addressed by techniques?
JT: describe same thing
CMN: at Project Manager level, may not read techniques
MK: GL should only address what; Techs address how; separation should be absolute
CMN: added to "at min" and "more advanced" parenthetical (required) and (suggested)
JR: advanced s what would be a really well done implementation
CV: if required, why not just say it explicitly and not parenthetically?
CMN: required and suggested as names?
CV: yes
JT: could not do minimum but could do maximum
GJR: why not "base functionality"--defining base functionality, not a minimum requirement
CV: agree
CMN: would like to keep both sets of words there for the moment, and reanalyze later
MK: usability testing of verbiage important--we know what we mean
CV: basic functionality clearer from implementation point-of- view
KD: basic as minimum -- Ruby has basic conformance - really the minimum you can do to support Ruby; and the full implementation
JR: at minimum have to do to barely pass; better implementation might be different
GJR: why is it there, then if not normative?
JR: advanced doesn't necessarily build on minimum
GJR: not minuted
JR: in 4.1 at minimum, prompt author to manually check; advanced technique is to automate all checking--no prompt for check; advanced is not minimum plus
CMN: if the basic requirement isn't subsumed by advanced reeq, haven't correctly distilled basic req; in 4.1 case, basic requirement is each of these things are tested; basic is hassle user every time, advanced makes easier; KD talked about basic and full, but that breaks down with regard to accessibility; advanced is "here is one way to take this further"; at minimum should be normative--needs to be expressed in way that is normative; have to work out exactly what we want as functionality
JT: does everyone agree that base should be subsumed by advanced?
GJR: yes
JR: not sure
MK: might need to reword some checkpoints
JT: not referencing what we have, but what we intend to have
// RESOLVED: at minimum should be subsumed in "advanced" //
CMN: should base functionality/minimums be normative
JT: if stated in terms of user functionality, then, yes, normative
JT: do we want to structure further explanatory text that follows each guideline?
// NO //
JT: should require what needs to be done and what is required for purposes of ATAG GB: should we cut "see also" up into sub-components?
MK: 2 headings: one which links internally within GL and one that links to Techniques document
CV: "at minimum" or "base functionality"
JT: either label should work
CMN: at least for first draft, would like to keep "at minimum (required)" and CV: developers need to know what the basic functionality is MK: like basic functionality or normative, rather than required CMN: for those things, they ARE required JR: put basic functionality in parenthesis following "at minimum" so that it is easier to trace history/evolution of document CMN: "at minimum (basic functionality)" and "advanced (suggested functionality) JR: things that wouldn't be acceptable as a minimum need to be addressed CMN: inclined to put in "insufficient" category GB: put statement of what isn't satisfactory in "at minimum" verbiage CMN: preference is to keep examples in techniques GJR: rather have negative examples in techniques JT: to review: 1. checkpoint text with priority level 2. checkpoint sub-text, includes: A. rationale -- OPTIONAL B. at minimum (base functionality) -- REQUIRED C. advanced/suggested functionality -- OPTIONAL D. see also (links to other checkpoints and to techniques) -- REQUIRED JT: does everyone agree? // YES // TECHNIQUES STRUCTURE // CMN displays a sample technique // CMN: current structure of Techniques list: Relative priority checkpoint 1. ATAG Checkpoint number; ATAG checkpoint text, ATAG priority, and link to checkpoint in ATAG 2. grab-bag of techniques identified iconically by kind of tool they apply to-4 diff types: markup editors, multimedia tools (sound, movies, video); content management systems (courseware? - new category? Cross category?); programming environments (build applets, scripts); other suggestions: conversion tools (transform static content from one form to web-ready form); courseware; 3. for relative priority, lists relevant WCAG checkpoints; identify types of tools they are relevant to, 4. require or suggest (organizational structure and inline declaration) JT: filter techniques by tool category, required or suggested; JR: removed AERT document from ATAG techniques GJR: moved to an appendix or dropped? JT: will be in Techniques CMN: stripped out a bunch of stuff and resent to WCAG to address GJR: is there a public list with a URI CMN: yes to first, no to latter JT: structural suggestions? CMN: if something is required or necessary, should have explanation of why; GJR: shouldn't that "why" be addressed in GL? CMN: if expressed as a why, then gets into peoples' heads quicker; grouped by "things to do" and "references" GJR: is there implied or explicit hierarchy CMN: things we think are necessary appear before things that are good ideas JT: used to have sample implementations JR: fake tool examples CMN: in some cases have examples from real tools, too, such as HomeSite GB: items marked as required are restatements of "at minimum" JR: no-things that we as WG thought you couldn't not do and not comply; provide long descriptive text for clip art collection GJR: organize by functionality GB: required to me sounds normative; required things belong in guidelines; not hard and fast requirements JR: agree as GJR pointed it, it is a bad label for a techniques document GB: if working with an AU tool, would go by tool category CMN: label "required" needs to be changed-suggestions are welcome-send to mailing list; going by category makes it easy to generate something that drops irrelevant categories // example Graham Oliver's evaluation of Lotus - said markup editor and content manager, and addressed only techniques labeled as such // JT: changes? suggestions? Change "required" if anything marked "required" consider moving to guidelines document GJR: modularize techniques a la WCAG? Realize that many tools cross categories CMN: attempting to modularize via technology (transformations); need more categories and more techniques; what we have now caters to overlap-some relevant to only 1, some to 3; development team chucking point of GJR, can't nor should we try to, split up GJR: blah blah blah CMN: strip out all the stuff that didn't fit, thro GB: organize the content of this document in XML format, and then transform using XSLT, and use that to organize modularization CMN: the document is in XML to provide that type of functionality; number 1 priority for techniques is to be able to produce different documents through transformations KD: document will be used by developers and evaluators, so is good idea to have different views depending on use; scenario filtering or separate document with checkpoints for each category CMN: what kind of tool are you working on? (checkboxes) leads to what is relevant to those types of tools; can't split out evaluation and developer stuff at this point GJR: needs to be WG control over filtering-if used for dev or eval, we need to filter out base functionalities that need to be addressed JT: evaluation techniques - part of this document or in separate document CMN: currently part of this document by sticking them on the end - expedient, but not ideal; evaluation techniques are much less mature than AU techniques; not very strongly identified, test cases that haven't yet been developed, open issues and questions GB: evolution guidelines not as important as techniques discussing now; need to have a tool before you can evaluate it MK: I agree-guidelines and techniques for implementation and techniques for evaluation JR: evaluation techniques could be used to bypass implementation techniques CMN: implementation techs in principle are reverse engineering-here's the end point, here's how you get there JT: evaluation document specific process used to evaluate authoring tools GJR: proposed: make evaluation section a different document with example of EARL assertion // ACTION GJR: talk with Sean Palmer about providing EARL assertions about an authoring tool based on ATAG // // ACTION CMN: NUMBER TECHNIQUES!!! // JT: present structure: Techniques - required and suggested References Samples/Examples/Sample Implementations JR: overlap between tools needs to be explicitly expressed JT: should be taken care of when sorted by rules JR: how are we going to signify strength of suggestion? CMN: should and may GB: why needed? CMN: sufficient and suggested - a technique or group of techniques is sufficient (WG says, if you do this, you have met the base requirement); JT: required things where you have to do X, Y, and Z, but you can choose what you do thereafter MK: collections of things that together form something sufficient; also have things that are dependent upon each other GB: if normative or required, should go into guidelines CMN: requirement is written in checkpoint; in technique, state it is sufficient; implementation techniques as a collection; combos of techniques that aren't sufficient MK: rather than required or sufficient in techs, this is one way of meeting the required checkpoint; tie back to what is a minimum GB: proposed: removed "required", when state "at minimum" say "to achieve this minimum, you have to satisfy Technique X, Y, etc." JR: too much bloat, too many mappings CMN: GB's suggestion is what we want to do, but should keep it in techniques until individuals can filter guidelines document themselves to get that sort of view GB: re-propose when have more content-need to see what you think is required CMN: what I hear GJR saying, is that we need to be thinking is there stuff in the techniques document that is an out-and- out req, because those should be in the GL, not the Techs; don't think that changes the discussion GJR: unminitued comments on baselines and responsibility-we are where the buck stops CMN: think that this WG has a responsibility to say these are the baseline requirements and what you have to do in order to meet the requirements-we just have to provide the whys on 4 or 5 different levels - if you don't, the tools will be crap-need to provide sufficient level of support; goal is to get implementation KD: if I'm a developer and go to techniques and don't see anything that helps me, what can I do - where do I turn? No info on feature I want to add, but no; techniques are not complete in a sense, because don't know the future and new developments; suggestions, not requirements; techniques can never be exhaustive JR: good point; can't ever say anything is sufficient GJR: what is sufficient is provision of functionality, implementation isn't our concern MK: an author of a tool can have a type of tool we haven't even considered, so in techniques should have explicit link to mailing list for questions, suggestions CMN: right up in what this document is about - read GL, read techniques, ask working group; if get this far, we think you have met this req-not the only way, but basic satisfaction of this requirement; for those who are trying to meet requirements, that stuff is really important; it does make a difference how clearly it is stated what needs to be done; GB: answer to that question has to be answered in document for checking conformance; if just developed best authoring tool, but no specific techniques-refer to conformance document GJR: last 2 items for each technique: link to list, I have satisfied this requirement in a way you didn't imagine, and here's the documentation of what I did, how, and why with requirement that info be posted to AU list CMN: in evaluation techniques, should have very strong introduction to proper usage of documents - when you use techniques, when you use checklist, when you use guidelines, etc. // BREAK FOR LUNCH (12:30pm to 1:30pm // JT: in terms of discussion regarding structure, within techniques the required/necessary statements - should they go into evaluation techniques? Should distinction be dropped? Further thoughts? Technology specific or sufficient or part of a group JR: like CMN's should be and may be implemented language JT: but where should they go? GB: guidelines - if normative, goes in GL JT: and if not normative JB/CMN: techniques JR: if applies to a sub-set of tools, even if normative, should be in techniques, so as not to overload GL // RESOLVED: only cross-categories // CV: why not "possible implementations" JT: techniques: non-normatives = should CV: feasible way to implement, but not the only one JR: ATAG 1.2 - first technique is close to wording of checkpoint; how could you not do this and not satisfy checkpoint; JT: so why in techniques JR: migrated from older versions of ATAG; more you water down a heading, from required to possible, the less weight they have CV: techniques should just be implementation hints GJR: expresses concern about muddying waters between guidelines document which says do X at an abstract level, JT not exclusive categories-arbitrary; view model works well for type of software we are discussion; not exclusive categories JR: main problem - how to deal with what appear to be normative statements, but which aren't general enough to be a checkpoint, but too specific to be a technique CV: example JR: [reads 4.1 ] CV: is there not a checkpoint that already covers this - 1.5 in Wombat JR: no Wombat techniques GB: I've learned that we have at least 3 axes 1. Normative or non-normative 2. Technology independent or dependent 3. Multi-media or editing tool and all are independent as I see them; thought that GL contained all normative info, but doesn't fit well with what JR was saying; perhaps need another discussion of what goes in GL, what in Techs, and what elsewhere; could be used to determine what goes where; better for filtering JT: so many classes of audience GB: but first order of business is a usable document JT: original understanding of techniques was: instructions for implementation, not normative versus non-normative; probably a lot of required things in Techs CV: going back to GJR's point about a three tiered document GJR unminituted explanation of WCAG2 evolution: executive summary, guidelines document, checkpoint solutions, technology specific view, and techniques document KD: certain WGs have started to build test suites to test implementation; Techniques are a kind of test suite - recommendation on how to implement a specific part of GL; DOM WG has a submission process that helps people submit new techniques-someone responsible for testing, test passed by the WG, put into test suite (dated and verified); think Techniques very similar-not just evaluation techniques; is it necessary to have a very frozen document, or could it evolve in the future? JT: Techniques document will evolve-GL has longevity, Techniques evolve CMN: 2 types of tech-evaluation techs along the lines of a test suite; implementation techs are not directly test suite material; ways of getting tool to achieve requirement; perhaps should redirect energies towards making the evaluation stuff as strong as possible, even for a given tool type KD: would it be difficult to manage so many separate documents to synchronize? CMN: more work, but possible JT: suggestion? CMN: shouldn't build another document on top; every new document is a substantial increase in the amount of work that doesn't get done; useful to have "if you meet this technique you will satisfy this checkpoint" in the Techs; need evaluation techniques-should raise priority as a deliverable; one way of satisfying this checkpoint is to implement techniques 1,4, and 5; another way is..." GB: identify users of document-who is intended audience JT: we've been through that MK: might be good to remind ourselves JT: intended for developers of tools CMN: implementation techniques relevant to developersof tools and people who have nothing better to do than read specs; evaluation techs are useful for developersto see if meet requirements; by QA people performing testing (individual evaluations)-not sufficient currently; main guidelines document for all of those groups plus product managers-must be shot enough to be readable-something from which you could derive the techniques document on your own GB: for evaluators, knowing suggested techniques are irrelevant CMN: not irrelevant, unnecessary JR: prose at top of checkpoint not going to work-too many permutations, too many strands; turn a lot into if then statements would be a better approach-that would inherently decide if applicable - yes, no, doesn't apply JT: stick into views JR: could, but harder; first part of the "if" statement is "if converting footnotes and endnotes..." CV: many ways to do that-what do you tell developer? Might also have to put "if", "then", and "go tos"! JR: a lot of techniques could be removed JT: thoughts? MK: profiling by use - project manager, evaluator, etc. JT: not support for adding layers to ATAG; will have evuation techniques and implementation technique documents; should statements that don't apply to all technologies still an open issue // OPEN ISSUE: What to do with the "should" statements that don't apply to all technologies still an open issue // CMN shows example of techniques organization // JT: only takes care of one class of shoulds JR: too difficult to write combinations out CMN: no more difficult than doing "required" and "suggested" properly-that info is very useful, and this is a proposal to address how to retain it and express it better JR: like should and may better - if your tool allows docs with footnotes to be coverted, you may include them as inline content or through 2-way linking" JT: "if/then statements with "should" or "may"? JR: yes CMN: useful functionality to keep is being able to say, "the WG thinks that if you implement this tech or this combo of techs, you will satisfy this checkpoint"; needed for cross- tool applicability-some techniques are easier to implement in one tool than another; dev looks at combo sets, and chooses that which works best for their product and UI; here are different combos we think will do the job JT: should that be in evaluation techs, as per KD's suggestion? JR: the WG thinks X and Y are sufficient, but you should also consider... CMN: as developer, need a clear dileneation of what needs to be done without learning irrelevant material/info JT: we should move on; should or may good constructs; don't want to lose combinations of techniques; makes document more extensible
JT: satisfying 2.4 thread/posts - CV: one question on 1.1 and GL3 - they are basically the same; CMN: GL3 is only a guideline, not a checkpoint; GL a broad principle; only a requirement when becomes a checkpoint CV: but 1.1 is covered by checkpoints in GL3 JR: important special case of GL3 CV: each GL should tackle a specific problem JR: GL1 could state that all areas excet eqiv alternatives which are covered in GL3 CMN: should special case notes into "see also" bit JT: not the same; if interpreted as same, then not written well enough; 1.1 is critical as are each piece of GL3 CV: developer feedback that 1.1 and GL3 are confusing JT: operative word is "support" - steer the author towards the creation of accessible content-not just that the author can create CMN: 1.1 is "make it possible" CV: for those whose mother tongue isn't english, it is quite confusing // ACTION CMN: email list with proposal about clarifying langague used in Checkpoint 1.1 and GL3 // JR: 3.5 (ATAG1)/3.4 (Wombat) - argument built on ATAG1 techniques MK: go along with argument, but only partly; a lot of management of snippets about which I asked; realize now that what triggered question was use of "database" in checkpoint; has to have functionality of database, but could be a text file that stores this information
JR: I agree
JT: don't have an "at minimum" for this
JR: sent one to the list [reads proposal]
JT: does JR & MK's tweaks close the issue?
JR: this might involve a large number of multimedia objects; a semi-automated process, once a new object is used and an alternative defed for it, that binding is stored somewhere
CMN: think this text is fine (2001AprJun/0401.html)
JT: need change?
JR: if causing misinterpretations within WG, then yes
CMN: JR's text and arguments are sufficient for me
JR: change word "database" in techniques to make less technologically specific
RESOLVED: Adopt text for 3.4 from JR's post and remove word "database" from techniques //
CMN: 3 other checkpoints in thread source: 2001AprJun/thread.html#0142
JT: discussed in telecon-does it need to be reexamined?
JR: Heather Swayne wrote something about use of "prompt" in 3.1 - // JT reads from HS' post //
CMN: don't understand objection
JT: objected to intrusive dialog boxes
GJR: technology specific interpretation of the checkpoint
JR: interpreting "ask for" as throwing up
CV: use standard definition of "prompt" - many standard definitions of it;
GJR: if international standard definition, then already been reviewed f??
RESOLVED: change "ask for" to "prompt for" in sub-text of 3.1
JT: minimum requirement for 3.2 from HS is implement CSS
CMN: implementation technique and non sequitor
JR: HS' issue about relative priority note
CMN: list which apply, and which does not apply
GJR: how will it be implemented?
CMN: explain which relative priority checkpoints apply to a specific ATAG checkpoint
GJR: point to WCAG 1 for Wombat only or in perpetuity?
CMN: WCAG2 not stable enough to reference; if happens before Wombat finalized, we will switch to WCAG2 references; if we are in PR and they are only in LC, then we will stick to WCAG1; by working with WCAG1, we give ourselves more flexibility by doing the work now-use WCAG's checkpoint mapping to effect the change
GJR: should coordinate with UAAG list of structured elements and other relative priority things-what have they identified as meeting the criteria, how did they develop the criteria, does it differ from ours, etc.
MK: idea for a minimum is that tool should either label or classify attributes as being structural or presentational
CV: not helpful-technologically dependent JT: have a few techniques CMN: hard one GJR: PROPOSED: where a markup language supports presentation by styling, use styling by default; if author chooses a deprecated element or attribute, prompt him/her to use its replacement in the ML defined for the page/section/fragment, etc. only much more clearly, cleanly and well-stated // ACTION GJR/CMN: post GJR's proposal to list and incorporate // CMN: proposed for a minimum "tool asks author each time" JR: once for each or, for each thing, prompt - one prompt for all or many for one CMN: if tool pops up prompt and says "check all 68 WCAG checkpoints" JR: when does that pop up CMN: 2 questions: if pops up one dialog and says check all of this (Bobby model) - while not useful, it is the bare minimum; when it happens? Tool must do it CV: author should choose when; goes back to previous point about prompting
CMN: one way of choosing when is buying the right tool -- everytime you save or everytime you are in mode X; if author needs to ask for it, it changes what we meant; Macromedia extension works, because it it integrated into menu and happens when initiated by user
GB: tool must be useable; need to base minimums on reality and what is useable; reword text so that signaling mechanism is independent; tool has to make author aware that problems exist
JR: user pulls down menu item and says check the doc? GB: irrelevant - for things that need human intervention, need to be very general JR: break down into who initiates: author or user; second: is there any automation required for things checked off once by author? JR: tool should ask MK: have had this discussion before; some people will not accept a tool that does this and will only use a configurable or at-your-own-initiative tyep tool; had to do a lot of explaning to people why HomeSite always produced ALT when an IMG was defined; first answer is: it is a requirement of the markup language, but still received complaints from users CMN: 4.2 much less contentious to me with JR's proposal; HS said that having things in help is a minimum for 4.2; don't agree
JT: at minumum for prompting at the tool's initiative or the author's initiative JR: how is user given choice? MK: something happens for the first time with a box that says "don't warn me again"; if want to change, could go into options and do so JR: suggestion at save - "There may be some errors in this page, would you like to check?" JT: want to avoid a burried menu item or sub-menu item, so has to happen by default MK: automatic, but over-rulable GJR: red herring - tools over-prompt by default JR: want something difficultg to turn off, but unintrusive GB: should be very easy to disable if interferes with normal work flow of author JT: rather than binary choice, can have "check later" // WL joins by phone // CMN: important that we allow a mechanism where user says do this as way check happens, critical that those functions are right up-front and center; GL5 says "make sure they are clear" - perhaps need a checkpoint about putting 3.1 3.2.4.1 if are user intiated, P1 requirement that initiation of those is front-and-center part of UI - proposing a new checkpoing under GL5; must be omnipresent and obvious as a P1 requirement
MK: easy to do, easy to find;
JT: when user has initiated is the new bit?
CMN: for checking/prompting functions that are user- initiated, they must be front-and-center - P1 and refers to mechanisms for 3.1, 3.2, and 4.1
JT: looking at minimum statements for 4.1 and 4.2 - discussing who should initiate checking
KD: if prompt too annoying for user, what about a spell check underlining; if image is called several times on a page, don't reask each time GJR: redundancy is the key-offer many ways to accomplish a task JR: at least once per session (defined as opening a document and closing it), user must, at least once, be queried as to whether or not they want to perform a check - could be part of a dialog, its own dialog, a status line message GB: a menu called "accessibility" JT: authoring-tool initiated MK: one mode that the user might choose-batch processing JT: author have a number of choices, but one is on by default JR: if just see question, is that ok? MK: yes GB: tool should make the user aware that there are accessiblity problems so that user can see them in context; mnore than one way that can be initiated by users; JT: part of at minimum is that the checking mechanism be there! 2 aspects: who initiates and what functionality the tool requires CV: once a session too much
JR: change checkpoint to say "Assist the author..." at minimum, say what GB said, in new checkpoint 5.x go into details (multiple places, easiliy initiated)
JT: what about 4.2
CMN: may be initiated by tool or by author
JT: what functionality should the tool have at a minumum? CMN: at minimum ok to put onus on author; JT: link in an external checking tool MK: make people aware that these tools exist GJR: on a user defined schedule, and in a user-configurable manner, allow the user to check a file for accessiblity - functionality is: control over when, control over how, control over what is checked (granularity of check) JR: what about NotePad - GJR's definition would allow it to pass 4.1/4.2 GJR: to say that NotePad and WCAG constitute an authoring tool is akin to saying that access to document source and a good imagination constitute a user agent JT: 2 points: what is functionality and who performs it; who performs it? JR: check might be a sentence on screen or WCAG CMN: tool must ask the author to chcck each WCAG requirement; minimal satisfaction is go into accessibiloity check and spits out a list of things to check JT: has to be encompassed by more advanced tool CMN: more advanced tool has a check for each WCAG checkpoint which can be automatically checked and then asks for help with those which can't be automated JR: at minimum, tool must distill a number of checks from WCAG - not sufficient to put all WCAG checkpoints on screen asking user to check CMN: sufficient to hand up WCAG's checklist, please check these boxes JR: that's inform; tool must automate answers CMN: to pass 4.2
JR: no, 4.1 GB: as minimum requirement tool should be able to show the WCAG checkpoints that are applicable le to the document being edited; irrelevant checkpoints should be filtgered out by tool; ask user to check manually
MK: don't need to ask for LONGDESC if no images JR: large amount of automation required
MK: not too difficult to count tags - if IMG = 0, nothing; if 1 applicable, if none then not applicable
CMN: WCAG checkpoint listed by priority; says "in general" (has to have a test for this); "and if you use..." all can be tested for very trivially; those that turn up null, leave off list; very small requirement; acceptable minimum; more advacned than ask every question
PROPOSED (CMN) At minimum, the author must be prompted to answer questoins leading to an assesement against WCAG at relevant priority level for those parts of the WCAG checklist for the document being tested
RESOLVED 4.1 addresses functionality of tool - at minimum, tool must provide a list of questions relevant to the content being developed by the author."
MK: in general easy and less annoying
GB: always false positives; should be able to filter out questions about content guidelines
MK: if don't have IMG, easy to filter out
GB: a tool that would be able to avoid asking if the image has an alt when there is no ALT would satisfy the minimum requirement
GJR: all contained in the "in general" section of WCAG checklist JR: WCAG 1.1 contains at least 10 questions; who's going to distill the manual questions? Provide manual questions, filter GJR: organization by priority then by general (everyone needs to address) and then "if you use..." JR: least acceptable is one question per WCAG checkpoint GJR: at minimum is, if can be automatically checked, then must check using AERT techniques GB: state of AERT and detail CR: still being modified; great deal of detail; fairly complex algorithm GB: don't agree in taking AERT as being normative CR: can't have an "at minimum" - algorithm always going to be limited; going to end up displaying large chuncks of WCAG; don't think there is an acceptable "at minumum" MK: other extreme is reliance on automation
CR: some placeholder text is ok JR: currently have AERT as a technique; at minimum, let author know that there is a manual check; ideally, should automate to gtreatest extent possible; better the checker, the better the user experience CR: choose top 5 accessibility errors as a minimum GJR: would have to ensure that those 5 affect ALL users CMN: WCAG - 7 Priority 1 items; 9 conditional items (includes if all else fails) = 16 items; one important thing is that the final part of any useful check is always manual JT: check for all P1 WCAG checkpoints according to AERT?
CMN: never get developersto say yes to that JR: top 2 or 3 things - get them to implement some sort of checking functionality into the tool CMN: first automation is strip out WCAG questions that don't apply is: 1) easy; 2) better user experience; 3) leads to manual checking gracefully; that piece of automation is as unconctoversial as we can get, is low-cost, and provides good buy in; provides a platfrom from which to start JR: how to filter out?
CMN: "in general" can't be filtered out; the rest according to the WCAG checklist secondary line of organization ("in general" and "if you use...") MK: count number of image tags, if number is 0, don't ask; count IMG, TABLE, etc. GJR: use UAAG as basis - list of structural elements that must be traversable
JT: filtering out WCAG checkpoints that don't apply as an "at minimum" CR: going to end up displaying all of WCAG that way CMN: right, but better tools will do it in a better, more sophistiacted manner, and will be bought and actually used CR: have to specify all the things you're looking for CMN: basic and trivial if use WCAG checklist // CV leaves // // PJ makes his presence known on the phone, but cannot be understood; he will join at 1:30pm Amsterdam time //
TOPIC: TOMORROW'S AGENDA
JT: tackle new checkpoint and then continue with agenda?
RESOLVED: start with new checkpoint for GL5, at minimum for 4.2, and then continue with pre-set agenda
-----------
JT: still have 4.1 discussion in mind, so want to continue with discussion on 4.2; JR asked if we could review all checkpoints to ensure that content states what we intended it to state CMN: completed action item, and posted to AU list; don't have local copy
// CMN types up proposal for projecting purposes while the rest of the WG has coffee //
CMN: [reads checkpoint proposal] note that this is a P1 proposal; references similar P2 checkpoints MK: obvious or clearly identifiable JR: why 3.2?
CMN: one of the ones we came up with yesterday; 3.1 and 3.2 are fairly similar beasties for different special parts of an authoring tool; JR: and 4.2? CMN: 4.2 is simply, follow on from 4.1 -- think it would make sense
DD: what about a parenthetic, 2 word explanation of what the referenced checkpoints refer to so you don't have to follow them to find out
GB: for 3.1, if the tool opens up an inspector/wizard with a text input field to provide alt text, would that suffice? CMN: not quite, partly because doesn't include LONGDESC, and partly because it has to work with various other kinds of alternatives--OBJECT, NOSCRIPT GB: can we add this to the discussion of techniques
CV: old 5.1 already mentions integrating so why the new checkpoint--may be a conflict in priorities JR: could change priorities so that P1 to do 3.1, 3.2, 4.1 - - or roll into 5.2 with a change of priority JT: a checkpoint with a dual priority? CMN: would like to avoid that
JR: not a great solution, but a solution; sole function of new checkpoint is to modify the priority level and the visibility of things for other checkpoints -- new tack for the WG
CMN: reason we want it is to give us a way of saying, yes, you can do it yourself, rather than auto-initiated by tool, but has to be readily accessible; like to keep these pieces separate CV: doesn't quite make sense -- implication is need 2 buttons: one to satisfy the P1 requirement and one to satisfy the P2 requirement JT: new 5.2 is "naturally integrated" CMN: let's call new one 5.x JT: talking about naturally integrated, as opposed to visible and obvious CMN: P1 requirement is to make critical things obvious; as sit down to do an evaluation, if those are obvious, that gets you through the GL5 at level A; have to go back to get double A
CV: demanding an extra button, which doesn't make sense JR: could be the same button CMN: if meet 5.2, have met 5.1 -- need another "see also" to clarify/make explicit; if you do this work, part of it include doing this JT: might want to reorder checkpoints so that the old one immediately precedes or follows the new one JR: should put it in and try it out -- should we put 5.x first?
JT: might get comments that that is contradictory
MK: no, clear case of reusing JR: make sure you use the same interface for both MK: yes; menu item called "accessibility" is naturally integrated, and front-and-center if all checkers/features are available through the menu // RESOLVED: add 5.x following old 5.1 and number as 5.2; adjust other checkpoint numbering as necessary
JT: we should finish with 4.1 before moving to 4.2
CMN: proposal contained in: <http://lists.w3.org/Archives/Public/w3c-wai-au/AprJun/0175.html> GB: would like to add that this functionality can be delayed by the user CMN: that's implicit--functionality has to be available, user doesn't have to use it CG: always displayed doesn't sound optional CMN: still have to run utility/initiate routine, but when you do so, it only brings out the relevant checkpoints JR: meant to mean always displays a certain type of question // ACTION: CMN/JR: work on wording for 4.1 // CR: who's to judge if it simplifies the process of checking; JR: this is just an at minimum -- techniques will define more CMN: question is, is a particular UI useful (implementation detail) or does it check JT: "assist the author" is the key bit CMN: if the thing doesn't check against all WCAG checkpoints, can't pass CR: not part of checkpoint? JR: explanatory text CR: if have an accessibility checker, but users don't like interface, would they fail, because users don't like complexity? CMN: can't fail if UI sucks JT: wouldn't be assisting the author CR: but they think they are CMN: some tools have great interfaces and others don't -- some people love wizards, and others love command line thingies; what the subtext says is that the tool helps the author check for accessibility problems, rather than leaving it all up to the user CR: as long as there is any utility CMN: only if meets minimum MK: good point about usability JT: if naturally integrated, then whole UI may suck CMN: different strokes for different folds DD: why is "at minimum" for all checkpoints and not just P1 or relative priority; if want to be level, do all level a, so why the "at minimum"? CMN: minimum should say, every checkpoint for the priority level claimed DD: ok MK: is there any indication of when we switch to referring to WCAG2? CMN: no idea; in principle, can go all the way through with WCAG1, but hoping that they will finish faster than us so we can reference WCAG2 JR: this checkpoint requires the tool to provide the author with tools that support the process of checking CR: allows rather than supports? JR: anything is allowed--support is active; add "check each and every WCAG P1 checkpoint" to the at minimum GB: has to be designed so that when it is used, it always displays the relevant questions // CMN announces that the AU WG has been re-chartered -- WE EXIST ONCE AGAIN!!! // // and there was much rejoicing... //
-------------- CMN: don't think I had any comments about 4.2 -- did I? [reads checkpoint aloud] -- sounds good to me
JT: comments? GB: what is context sensitive help
CMN: identify the problem and link the help to the problem JR: always do same thing to get the help, but when invoked, goes to the relevant part of help CMN: just say that help has to be linked to problem -- no implicit or explicit mechanism implied; provide a line number and what needs to be fixed, a ToolTip type popup help message as appear in windows and MacOS JT: proposal that we review each of the additional text (checkpoint sub-text) to ascertain if they correspond to the model agreed upon yesterday; start at the top of Wombat
// CMN displays Wombat on the projector //
JT: note that there are a few at minimums that aren't in the current Wombat draft -- each should contain: 1. Rationale 2. Context Statement 3. Minimum Implementation 4. Advanced Implementation 6. See Also (includes links to techniques) // ACTION CMN: get new draft out by end of the week // MK: couldn't we just have a link to the definition of some of the terms CMN: just putting in all the words right now; probably all the stuff in brackets will disappear, but that links this draft to the last, so people can trace evolutionary path JT: phrase "one common way to minimally satisfy this..." should be dropped CMN: yeah JR: yeah JT: that statement isn't a functional statement CMN: not a minimum requirement, either -- fairly clear about that MK: "one common way to satisfy..." is a technique JT: let's move it to the techniques // RESOLVED: move second sentence of 1.1 "at minimum" to Techniques // JT: other edits? // NO // JT: moving on to 1.2 -- comments? JR: this may not be reversible? CMN: if take something and convert it, you may not be able to convert it back to what it originally was; point is that the minimal conversion -- stuff with structure dumped into plain text, can't get structure back -- that's the irreversible bit; in an advanced implementation would track changes so could be undone DD: if save as ASCII, going to lose structure; should be a message to the user such as that in Word that warns that you will lose information -- suggest use verbiage from Word GJR: can provide text that pops up when attempting to save Unicode to ASCII using NotePad in Win2k Pro -- it's of the "some of the characters will not be able to be stored correctly/retrieved" JT: please propose something based on that // ACTION GJR: provide example warning text // CMN: so where not reversible, author should be informed DD: read in an HTML file with accessibility markup, the tool shouldn't strip it out GB: why transformation and conversion tools? Aren't' they synonymous? CMN: have a definition of transformation and a definition of conversion that say they are the same; having both in checkpoint text caters to both factions and those who think that there is a difference between the two JR: seems silly to have 2 terms that are synonymous; just going to foster confusion, not bring more clarity CMN: which do you want to take out? CV: Tablin is a transformation--why not use it and end the sentence? JT: a lot of people use conversion in developer community CV: I use neither -- import and export are what are most commonly used MK: could work one word into sub-text JT: no rationale statement -- could use that to use all the terms -- import, export, transformation, and conversion // ACTION JT: create rationale text for 1.2 using the terms conversion, transformation, import and export // JT: [reads at minimum for 1.3] MK: can be a lot of decisions made by tool that don't have any relevance to accessibility; what about "any decisions made by the tool that impact accessibility" CMN: don't think it is necessary JT: functional enough? CMN: yeah JR: yeah -------------- Checkpoint 1.4 -------------- JT: [reads 1.4 in toto] CMN: minimum built into the checkpoint already MK: can't have an at minimum apart from the checkpoint text CMN: yeah -- "just do it" JR: restate in at minimum JT: the at minimum is the clarifying statement, so move what follows "For example...." to the "at minimum" field CV: relative priority -- if claim double-A, should be double-A CMN: good catch! CV: don't know why separate multimedia, applets, images, and scripts -- everything must be accessible is simpler CMN: example stuff is just an example--a selective example JR: edit top part and move to rationale -- that's where examples should go JT: it does clarify the checkpoint CMN: not all of it does JT: do want to highlight templates, so I would leave it there; example could be turned into the at minimum statement CMN: not sufficiently inclusive // RESOLVED: leave 1.4 as is for now // -------------- Checkpoint 1.5 -------------- JT: [reads checkpoint 1.5 in toto] CMN: second sentence in there has caused a lot of confusion; basic idea is that it is perfectly acceptable for a tool to say either I'm going to crunch this markup or I'm going to reject this document; tool must be able to reject a document if it wants to change the markup CV: please repeat CMN: author might say "don't change my markup, no matter what" and the tool may sue for alienation of affection MK: some tools may simply refuse to open documents that are in a particular format/ML JR: if the author declines to make a change, it may not be possible for the author to effect the change CMN: how about "It is acceptable for a tool to reject a document" JR: does that need to be in the "at minimum" text? CMN: I think so MK: you at least want to know what is happening GB: we need techniques for this checkpoint CMN: look under 4.3 -- this checkpoint moved in Wombat from GL4 to GL1 MK: technique: highlight all those things it cannot process to indicate to the user what will/may be lost when document saved -------------- Checkpoint 2.1 -------------- CMN: [reads text of 2.1] JT: at minimum is "W3C specs have undergone review..." GJR: that's rationale, not an at minimum CMN: I'll move it CV: what constitutes "appropriate for a task" -- what's the minimum and the meaning of "appropriate for a task" CMN: it is actually useful -- PNG isn't good for large masses of text JR: use W3C stuff -- if you really want to use pictures of text, use SVG fonts CMN: the "appropriate" thing is really an "out" for developers JR: the "at minimum" is "just do it" CMN: question that at minimum has to answer is: when is something available? When is XHTML Basic available and when is it appropriate for a task; at what point does an AU have to implement XHTML Basic? now? in a year? in ten years? one of the things this checkpoint says is, "the latest version of the HTML recommendations are various XHTML recommendations" -- must those be available in order for the AU to pass, and how does one make the decision when to support a particular markup language or suite of markup languages MK: the question, then, that immediately occurs to me, is "available in the wild, or in the tool?" KHS: could use a term such as "widely supported" // AT MINIMUM TEXT FOR 2.1 MARKED AS OPEN ISSUE // -------------- Checkpoint 2.2 -------------- JT [reads checkpoint in toto] -- no "at minimum", but a rationale CMN: propose "inform author if markup is not valid" as a minimum; pretty weak, but better than nothing; a tool need not force validation; an author may say, I'm writing something that conforms to an unpublished version of HTML GJR: or to my personal extensions to XHTML JR: this checkpoint refers to the markup that the tool generates on its own MK: tool could say, then, I know its invalid, but I'm going to do it anyway CMN: ah, that's the fatal flaw in my argument--at least we're all awake and paying attention MK: don't think the checkpoint needs an "at minimum" JT: that's the second case we've come across where no "at minimum" is necessary JR: 1.3 is similar and has an "at minimum" (author override) -- should we grab that one and tweak it? CMN: any markup produced by the tool must be valid, even if it uses personalized extensions, because they need to be added according to spec; propose that keep in for now -- issue is, do we need it? // OPEN ISSUE: IS AN AT MINIMUM FOR 2.2 NECESSARY? // -------------- Checkpoint 2.3 -------------- MK: if tool only supports a sub-set of a markup language, that would be ok if that bit is valid CMN: that's covered GB: this checkpoint doesn't cover templates? CMN: templates are covered by 1.4 -- they're not automatically generated MK: yes, but what about tools that generate templates? HomeSite generates templates in response to user input, but it's HomeSite that generates them JT: then it is covered because it is the tool creating the markup JR: we say that "pre-authored" content have to conform to WCAG, but doesn't have to be valid CMN: actually, WCAG demands validity JT: complying to WCAG implies validity JR: if WCAG requires validity, do we have to? JT: possibly not GJR: "first step to creating accessible markup is creating valid markup" is a mantra that runs through all WAI/W3C work -- part of the adherence to standards argument, and PF's raison d'etre =========== GUIDELINE 3 =========== ------------------------------------------: Is the Guideline text "all that it can be"? ------------------------------------------ JT: [reads guideline text] -- the bottom line is, "assist the author" CV: same problem as before CMN: guiding the author to produce accessible content is far different from allowing an author to produce accessible content // RESOLVED: change to "guide the author to produce" // -------------- Checkpoint 3.1 -------------- JT: [reads text of checkpoint 3.1 in toto] MK: shouldn't that be "alternative text"? CMN: we have a thread on this from the list <http://lists.w3.org/Archives/Public/w3c-wai-au/2001AprJun/thread.html#0141. html> JT: where's the stuff we put into it yesterday? ALL: in the minutes! // GJR suspends minuting in order to post minutes from 18 June 2001; minuting subsumed by live editorial session in which CMN tweaked document // // resume GJR minutes // -------------- Checkpoint 3.4 -------------- GB: learned that last week that there is a tool that can describe a chart; user might want to use that tool to generate description of the chart CMN: how does that not get covered by 2nd sentence in checkpoint? GB: doesn't allow for what I'm trying to do -- import text; JR: put an "or" in place of the second "do not" GB: ok CV: replace confounded with plain English, please // ACTION CMN: wordsmith rationale for checkpoint 3.3 // GJR: propose CMN: prefer to have widest review possible GJR: want to preclude a whole set of issues from arising; make sure that the document is extensible--we've put effort into making the English the clearest and simplest possible-- it's time we put our efforts to the test; we need to ensure that as we move forward, we do so in tandem with those who will eventually translate Wombat when it stabilizes; if we want the widest review possible, we should make sure that, whenever possible, benchmark drafts are issued in more than one language, and the only way to ensure that is to get the translators to follow the document's evolution // ACTION GJR: contact translators to organize a pre-public review of Wombat to ensure that verbiage is translatable // JT: how about "impeded" rather than "confused"? MK: some text should be moved to techniques CMN: drag out example and put in examples MK: second sentence is a technique JT: put in techniques // RESOLVED: second sentence of checkpoint 3.4 will be moved to Techniques // CMN: fact that should be offered only if human-authored or explicitly associated with the object // RESOLVED: use the term "explicitly associated" // JT: still doesn't have a minimum CMN: this is a thing to not do, so minimum is "how many times and under what circumstances does this happen or not happen" // RESOLVED: adopt CMN's further tweaks to verbiage about "explicitly associated" // -------------- Checkpoint 3.4 -------------- JT: comments on list? thought there was a mis-numbering and a comment CMN: comment was just "these are misnumbered" [JT reads text of 3.4] JT: required or encouraged in rationale? CMN: remove and replace with new bit I just wrote // RESOLVED: effect CMN's changes to 3.4 // JT: at minimum statement? // CMN checks minutes of 18 June 2001 meeting // // RESOLVED: add GJR's verbiage (from minutes to 18 June 2001 F2F) to checkpoint 3.2 // GB: want to use the FONT element--first time I use it, I'm told, use CSS to do this; if I want to keep going, does the prompt reappear each time I put in a FONT? CMN: 1.3 and 5.2 says, when you want to do presentational stuff, prompt to do accessibly DD: problem with prompting CV: covered in another GL DD: all prompting must be configurable JT: a lot of stuff to support prompt -- even an entire appendix CMN: propose we leave for now and review in context when new draft published ------------- AGENDA REVIEW ------------- JT: at 1:30pm we are going to have Graham and Phill calling in for the Lotus evaluation; still have to discuss EARL and ATAG; need to work on evaluation techniques very badly; need to fit EARL into discussion; CV leaves at noon--is there anything specifically you want addressed? CV: will follow on list--GL5 and GL6 might be combined to make document stronger; traditionally in HCI they are all considered part of the interface JT: people seem to think that GL6 applies to the accessibility of the authoring system, which is part of GL7- -if integrate GL5 and GL6 as per CV's suggestion, that will make the distinction clearer // PROPOSED (CV): merge GL5 and GL6 // JT: problem--things in GL6 that may be perceived as inherently contradictory with GL5 MK: help documentation is something separate from the UI CV: I disagree MK: sufficiently different aspects of the UI to be delineated GB: don't understand why merging would be problematic JT: natural integration addressed in GL5; part of GL6 is about a "dedicated section", which contradicts GL5 MK: difference is GL5 is more about how UI appears to user whereas GL6 addresses content of documentation JT: checkpoint 6.2 could be moved to GL5 -- that might be a cause of confusion MK: difference between what needs to be there and how it needs to be made available JR: would prefer it stays where it is; ensuring that all examples have all required accessibility features JT: strongest point of 6.2 is make examples accessible; made more general and lost that succinctness when generalized;
JR: rephrase 6.2 so that it doesn't sound like it should be in GL5
// RESOLVED: rephrase 6.2 so that it doesn't sound like it belongs in GL5 //
JR: "ensure that all examples use accessible and valid markup"
CMN: are you reading the checkpoints for GL6? There are 3 or 4 messages on the topic JT: not yet, just discussing the proposed merger of 2 GLs; point to make in 6.2 is not the naturally integrated, but that all of the help and documentation should in and of itself be accessible; that it needs to be part of the whole thing is an ancillary part of the requirement
GJR: modified JR's proposal to state "ensure that all materials intended to provide the author with guidance utilize accessible and valid markup"
JT: need to include authoring practices; all roads should lead to Rome JR: document inaccessible things your tool allows the author to do
JT: primary thing is the examples GJR: "ensure that all materials intended to assist the author in the creation of content utilize accessible and valid markup"
JR: why a dedicated section? JT: originated in GL7 so that people could find accessibility features of the tool
MK: if you can't manage to have integrated rewritten help, at minimum, have a dedicated section JT: yes, 6.3 could be a minimum to 6.1 JR: minimum for 6.2 JT: as it is currently phrased
JR: or is 6.2 an advanced solution for 6.3?
MK: that's what I'm trying to get at bidirectionally; help content may not specifically describe how to do it; current version of HomeSite has an HTML reference in it that comes from a third party -- it doesn't address the tool, just provides general guidance
JT: but still get to the info through the tool
JR: new 6.x "document the process of producing accessible content"; 6.y "document how to do it in this tool (minimum: in dedicated section, describe..."; advanced: naturally integrated into documentation/UI
CV: requiring that every tool has a tutorial addressing accessible web design JR: make a lower priority -- already in ATAG as P3
CV: wording says document process of producing
CMN: current wording says "list things you can use"; JR's wording implies, include a tutorial
MK: dedicated section as an at minimum is that a lot of tools reuse third party tutorials
CV: I read 6.3 as dealing with guidance on how to create accessible content WITH the tool, not in general
MK: can't say that as an at minimum--a more advanced solution
CMN: this is a P3 checkpoint, so can say what the very best tools will have
CV: specific to the tool
DD: also overlap with prompting -- strict, loose, by priority
CMN: no need for a dedicated section
JT: otherwise, 6.1 6.2 and 6.3 can all be rolled together
CMN: 6.3 is document the process
MK: could be a dedicated section as a minimum -- can add to it, but can't change what you've licensed
CMN: 6.3 doesn't need to be in a dedicated section; needs to be there; integration lower priority, a separate section also a lower priority
JR: first proposal makes that a technique; WG said, leave it in as a requirement
DD: yes, because it is a P3 thing; higher priority is to have accessibility addressed wherever appropriate/necessary
MK: if describes how language works well, may describe accessibility, so then you can add
JR: dedicated section on how to write HTML plus an addendum on how to create accessible content
DD: think of it as a tutorial CV: leave integration to the developer
CMN: what we have at the moment are 3 different requirements; 1) list of features you can use to create accessible content (P1); 2) stuff about creating accessible content permeates help and tutorials--that is a P2; the third is explain how to use the tool to create accessible content; propose have a fourth requirement at P3 which is to collect all into in a dedicated section, noting that you must first meet 5.2 (integration); rationale: many authors want to learn specifically about accessibility because they already know how to use the tool
JT: then why have 6.3 and 6.4?
CMN: meet 6.2 and 6.3 you have to read the whole manual; caters to advanced/experienced users versus beginners
JT: what's the difference?
CMN: one addresses features and one the process
CV: don't think should be a conformance requirement
GB: include in meaning of documentation, links and references to additional material must be available as well; 2) give me the outline of a possible tutorial
GJR: [unminuted] GB: tell them how to use features while telling them how to crate the page JT: that's 6.2 GB: talking about describing the process; producing accessible content is the same as authoring JT: ideally as telling a user how to author, tell them how to author accessibly--that's the intent of 6.2;
GB: then don't need 6.3 MK: I'm talking about a separate section and CMN is talking about a separate section for 2 different reasons JR: and doing 2 different things; still only see 2 things here and a bunch of minimums and advanced
MK: my point comes from the very real and practical point that want to include HTML reference that isn't quite up-to- date, but is quite good--big whole is doesn't address accessibility; want to keep it and add another section about accessibility JR: failing a P2 checkpoint to satisfy a P3 checkpoint
MK: better than just throwing the whole thing away; CMN's point about new and existing users is valid--advanced users just need to learn about accessibility, not the tool itself
DD: maybe MK's suggestion is really a technique MK: then dependent upon being integrated
JT: what is 6.3 adding? What is the distinguishing point?
DD: dedicated section JT: main point of 6.3 that isn't covered in 6.1? CMN: partly covered, but that is why it is a P3 under a P1; 6.1 could be a simple list of things, 6.3 explains their use JR: going to do my own rewrite // ACTION JR: propose restructuring of GL6 on list // JR: anyone else who would like to do so, please do // ONE HOUR BREAK FOR LUNCH // ----------------- TOPIC: EVALUATION -----------------
// Graham Oliver (GO) joins, once around the room with introductions, William Loughborough (WL) joins on IRC
JT: waiting for PJ to join--wait one more minute before we start; start with evaluation and move directly to evaluation techniques
// CMN pings PJ, DD fixes(?) the phone //
JT: GO, CMN sent your evaluation to the AU list and WG was asked to review--please give a summary of your findings and then comment on the process and make recommendations for making the process easier or the guidelines better
GO: can do; although want to do it the other way around;
JT: ok
GO: sent summary to the list; 22 hours of solid work in 3 or 4 hour chunks; sixteen hours dealing with CMN's feedback on my original report; GL 5,6,7 much easier because most of the questions there weren't relevant to Domino; found it a bit of a frustrating process--not understanding some of the questions was my main problem, but that could be due to my own ignorance of the area being asked about; technique to help would be to give one or 2 examples to go along with the questions
JT: questions are evaluation tech questions
GO; yes; example: "when an extended graphics superset..." -- didn't know what that meant--had to ask CMN, who gave an example, which allowed me to answer; have to assume a certain level of base knowledge on part of evaluator
JT: did it help to go back to techniques when questions like that arose
GO: no cross references in version of document I was using-- would have to be a link to a definition for that to work, otherwise, too long a process searching for that for which I was seeking an explanation; in order to get started had to break up document into manageable chunks; only going to evaluate for P1, so had to reformat document to do that;
JT: would it be helpful to have evaluation techniques in different views
GO: definitely; chunking it would be something that would have made it easier; actual process itself, if web based, would have been easier; would have liked to have done it all online; mucking around with HTML files and Word documents; made things a bit tricky for me; ended up doing most of work in Word, then converting to HTML; caused a few problems and issues that had to deal with outside of main task; administration of test and gathering of tools to record results; web-based interactive form set may obviate that
JT: something the WG has talked about, but lack staff resources WL: tools for doing that are so bad that it is hard to do it properly; using these kinds of tools to get on the web; when convert from Word to HTML is a microcosm of what I'm trying to say
GO: positive side, it increased my knowledge of the product- -felt that I knew more about the product after performing the review; aware throughout that Notes/Domino a bit of a special case--not a web --site building tool from the ground up--HTML capacity bolted onto it afterwards; very unlikely that Domino in anyone's mind when came up with list of questions; still able to tackle most of the questions, but a lot weren't relevant to Domino--made my job easier, but perhaps something that the WG should think about;
// Phil Jenkins (PJ) joins //
GO: just about finished talking about process; reasonably satisfactory process--felt I was doing something useful; intention was to produce something that might be of use to Domino and the AU WG; don't know if I achieved that, but felt as if I had done something useful
JT: summary: in terms of process document, need links to supporting material, examples are helpful, interactive form would also be helpful; positive side: despite fact that Lotus not in our mind when ATAG written, still possible to perform evaluation;
GO: had to decide to make P1 evaluation; limited it to P1 because that was too big a task; spent 22 hours or so just on P1
JT: other thought would be sorting of checks according to type of tool you are using (these apply to my tool checklist)
GO: made a decision up front that Domino fell into 2 of the 4 categories; GJR asks GO a question GO: document I did the evaluation against isn't same as current version; relatively easy for me to follow the path I created once I created it--didn't need to jump outside to other resources once I determined and blazed a path; like that it allowed me to stay within the document
CMN: first section of Techniques document lists techniques for implementation; final part lists what tests one can do; describes testing process and desired results
GO: sections 4,5,6,and 7
CMN: no, bunch of Techniques according to GL, followed by Techniques for Evaluating Authoring Tool Conformance; list of tests you can do and whether checkpoint sufficient as worded--did you use that? My impression is that you went through the techniques and said, does this, doesn't
GO: not quite understanding the question
JT: document that you used was not the one that is up there at the moment?
CMN: used current rough draft of Techniques
JT: did you use the end section?
GO: not sure--example please?
CMN: two-thirds of the way down
GO: oh, boy--don't think I've looked at this; doesn't look that familiar or friendly; similar stuff, right--rephrasing of questions, right?
CMN: goal: states it as an evaluation process to make it easier for you, but the fact that it intimidated you on first sight, is good feedback
JT: tried to bundle questions according to content type-- thought was you could create an image and answer all questions associated with that, so that the evaluation flows better as you are using the tool
GO: can't talk about this part of the document; might work for a standard web development tool, but not sure how much I would have gained; document length -- these documents are very very long--understand they need to be complete and thorough, but why as individual documents? One big huge document harder to deal with -- would have preferred if broken into chunks;
JT: format you would prefer? GO: want small bites--little chunks; that's my preference JT: web-based document divided into bits GO: gives me a sense of accomplishment/progress to put something behind me--just a personal preference JT: well structured hypertext document
GO: talking specifically about length; formatting thing-- lots of individual pages which are smaller and easier to digest, rather than one great big long document
JT: PJ has joined to discuss evaluation of Lotus--would you go thorough that? GO: my understanding was that we were going to concentrate on process, not findings; lot of easy findings in my review- -not applicable or not done, which made my job easier PJ: one comment on the process--identify the version and the environment that you are running Lotus on; need to make sure that that information is provided in every evaluation
GO: absolutely; I was remiss in providing that PJ: state class of tools up-front; mention categories it doesn't apply to as well as those it does; purchasing agents like that sort of thing GO: sure, absolutely PJ: just a comment back to the WG about need for info; need a minimum set of background info before evaluations published
JT: no disagreement--discussed before CMN: asked for up front in front matter PJ: do we allow things to be published that don't meet those criteria
CMN: in general, no, our goal is to get useful info--if enough info that is useful, going to ask them what platform and version, etc. before I publish it; do try to update stuff every so often and track and put notes in things obsolete (this review is obsolete--the product has changed or there is a new review, etc.)
PJ: we found it very useful to developers -- Domino designer folks found feedback very useful
GO: glad to hear that! Goal is to produce something useful to somebody; basically, I've got a long established commitment to notes and Domino, and I'm a fan of the product; I also believe strongly in accessibility, and while I acknowledge work gone into making R5 better, know that when IBM decides to make something accessible, they do it right; hope is that that what they have done may continue, and that the feedback I provide is helpful to IBM; highlight a few areas where output could be more standards compliant and more accessible; point-of-view is of a user who wants to have this
CMN: exercised editorial control over review process; not useful just to say "this tool is inaccessible on all levels"; value in partial basements is in illustrating implementations, proof of concept, demonstrating problems in ATAG documents; don't want to use AU web space simply to trash trashy tools; important to see what happens as tools move forward, rather than just nailing people to a post JT: points which have been made support a formalized process PJ: I did a quick summary back to the list--did you see that?
GO: no--not subscribed to AU list, but will grab off the web message reference: <http://lists.w3.org/Archives/Public/w3c-wai-au/2001AprJun/181.html>
PJ: text equivalents for sound doesn't apply to Domino
GO: specifically said that; delighted that you didn't find anything you fundamentally disagreed with; intrigued about HTML markup debates; rather inelegantly named "doc type sniffing" in IE6 -- are you aware of it? PJ: I am, but not sure if Domino developers are
GO: would have thought that when IE6 comes out, the pressure to be able to specify a DTD would increase, or so I would have thought
PJ: other big issues? GO: weren't many--3 major issues for me; fourth is a bit left-field--when you insert images into documents or forms, the ALT text should be input when the image is input PJ: topic of discussion in WG; context sensitive--helps author to define appropriate ALT text
GO: documentation -- would be useful to at least have something that highlights how to make the HTML Domino produces more accessible; lots of kludges, hacks, tricks that I've stumbled across that aren't documented within the product--think would be useful PJ: thanks JT: best if could find alternatives to the work-arounds
PJ: just commenting on 4.3 on list -- maybe as a minimum could say "document a workaround" as an example or technique JT: now part of GL6 -- distinction between authoring of accessible content and the means -- your point lies in the middle PJ: think it belongs in the "how you use the tool" part GO: sort of thing you get from PC magazines PJ: in IBM speak it is called a Redbook
JT: could you send something to us telling us the version, platform, etc. WL: is there an executive summary that says that a person with good intentions can use this tool to do good stuff? Can you meet WCAG using that tool? GO: in terms of P1, Domino's only barrier is the markup of tables--can't identify table headers using the TH tag (can, but only by hand, not using WYSIWYG tool); there is no executive summary--would be more like an executive book, rather than summary; using Domino to crate accessible HTML is difficult PJ: possible, but involved? GO: yes // Wendy Chisholm (WC) joins // WL: consciousness/awareness level needs to be raised so that people can be made aware that it is possible GO: that's where documentation aspect enters into it for me JT: we could help in terms of evaluation process; interactive form could give a summary of what has been filled in GO: done reasonable amount of work for an article on the topic--also includes how to create accessible web forms using Domino WL: could write a macro for Domino or Notes that would help you replace things with TH GO: no, you can't, as far as my understanding goes; some bits that can't be implemented PJ: have to defer to the developers on that GO: some bits that you can't influence--the TH is one that I highlighted PJ: have to import your own HTML WL: summary of the table's characteristics could be part of the documentation
// GO leaves at 1:30am local time //
JT: on the agenda, have 3 things to cover--moving through each GL to look at "at minimum" statements to see if they comply with our criteria; EARL and ATAG; Evaluation Process
CMN: other item need to get to is future planning--where do we go from here? Should we look at that now, and then have a break?
JT: try moving through checkpoints until 3:15 =========== GUIDELINE 4 ===========
JT: [reads at minimums from 18 June and earlier today]
WC: fulfilled by the document?
JT: Document being evaluated
CMN: in generals always come up; the rest as applicable (if found, ask, if not, don't)
WC: can check for a lot of the in generals
CMN: always have to do the in generals
JT: addresses question of whether it is sufficient to simply link to WCAG and tell the author to check that document applies
GB: text too strong still; "must always check when used those questions pertaining to
CMN: when this utility runs, it must check
GB: example: Useablenet can be used by disabling rules
CMN: extension does not pass when checks disabled; if environment allows for all checks to be done, it passes, if a conflict where all checked and one where none checked then the first passes, but the second does not; some of this is covered by conformance statement
MK: danger in linking to WCAG directly--if expensive to be online, they won't do it--can be helpful to use an external resource that is available online
CMN: you'd have to say in conformance that "this tool only applies when you are online"
MK: basic functionality has to be contained in the tool itself
-------------- Checkpoint 4.2 --------------
JT: [reads checkpoint in toto] -- comments?
// NONE //
-------------- Checkpoint 4.3 --------------
JT: [reads checkpoint in toto] -- comments?
// NONE //
=========== GUIDELINE 5 ===========
JT: [reads GL text] -------------- Checkpoint 5.1 --------------
// Judy Brewer joins by phone by mistake and leaves //
CMN [reads new checkpoint text in toto]
MK: even if initiated by tool, user should still be able
JT: remove first sentence then?
CMN: gladly--any automated checking must be able to be invoked manually easily
CMN: no minima for 5.2 and 5.3 -- isn't there a thread on this?
/* wendy picks up minuting from gregory */
Jutta reads proposal from Jan re: minima for 5.1 and 5.2 (see archives)
CMN put these in
JT for more advanced for 5.2, put warning instead of impede?
Resolved: put warning instead of impede, accept jan's 5.1 and 5.2
JT skipping 6, moving to 7.
GR part of checkpoint
resolved: 7.1 no minimum
WL Don't prevent someone from using notepad?
CMN You can edit anything you like.
resolved: 7.2 accepted.
resolved: 7.3 accepted
Marolein - move this to techniques?
PJ is that with or without a technology? some way for the alt to be displayed?
JT To the author
CMN w/out assistive tech
PJ At min, author must get to alt text and image file name.
CMN applies primarily to WYSIWYG. if have tag or picture, can get text rep.
PJ Talking about source. Author interested in source not rendering.
CMN Kind of.
JT Author also wants info about how displayed, but they can't themselves see it displayed that way.
PJ yes displayed is a confusing word to use there. Authoring purposes.
Issue: use other word than display.
Issue: move to techniques, but don't use functional statements.
GR If I get different display modes, I want to know the whole alt-text string. Also as it will be rendered using a particular browser.
PJ I disagree with Bill, we don't want to assume use of Assistive Technology. Should be functional requirement of authoring tool. Just have problem with "display."
GR Makes available to...
PJ Whether author or assistive tech doesn't matter.
CMN Goal is to publish this draft on Friday.
PJ When it says element to element, are there tools that do that?
CMN Dreamweaver, homesite, amaya
PJ I don't know that all tools do that. Can it be a minimum. Access to all, but navigate through?
JT Easier to navigate through doc.
PJ What if not element to element, but chunk to chunk, and within chunk. What if don't do minimum, but hierarchical?
CMN Meets it, you can navigate to each element.
PJ Sounds like sequentially.
CMN In XML there is no one sequence, can do breadth or depth. We don't say either way, just that you have to get to each one.
GR Minimum, go to element to element, not very efficient. Moving by chunk, is far superior.
PJ The phrase "to element to element" perhaps instead say "navigate to each element."
GR worried about situations where multiple people working on a document. Cases where you do need to go element to element. Gives me context.
Issue: phrase "element to element" should possibly be replaced by "navigate to each element."
GR Basic search may not turn up what you need as author. e.g.,can you search alt?
MK Add skipping or including tags.
GR Like a spell checker that says "ignore mailto: and ..." or "include attriutes or exclude."
JR Minimum?
CMN Should text search of renderable content.
GR alt is renderable.
JT then don't distinguish between renderable and not. basic text search should include tags and markup. probably simpler.
JR Like comments.
CMN problem with basic search source is when you have a propritary, binary format. is that a problem?
GR If don't have text transcript, no way to search.
JT Leave as basic text search, with "chocie to either include or ignore markup."
GR Search w/in markup.
Resolved: Leave as basic text search, with "chocie to either include or ignore markup."
MK Advanced include regular expressions?
JT Note issue: come up with other examples?
JR Techniques.
Resolved: put more in techniques.
/* break */
JT We have officially been rechartered. Everyone needs to rejoin. In terms of timeline, heading towards WCAG 2.0 with techniques document.
WL Hold out ATAG 2.0 until WCAG 2.0.
JT Right.
CMN Documents in play:
timeline for wombat: put this draft out. put a public first draft out soon (here's where we're at, we're going to do something with this in the future). Constraint: review. Next step: last call. Hard to set hard and fast dates. Like to get public draft out in about 3 weeks. Then send to process of first draft. Once we get to CR, see where WCAG 2.0 is at. If close to CR, wait for them. If not, go forward based on WCAG 1.0. More time we can spend in CR to look for implementations, the better.
With regards to techniques. Put out as two: evaluation techniques and implementation techniques. Put out as internal drafts. Update the note.
JT Implications of moving from WCAG 1.0 to 2.0, if go to last call, CR, etc. referencing WCAG 1.0. Go through whole process again?
CMN Rewrite references to WCAG, identify in 3.1 and 3.2 specifically identify which checkpoints are relevant. beyond last call, it may be that the changes to wcag 2.0 might mean that we have to go back. we're independent enough of the content of wcag that shifting the content won't cause us too many changes. the point we would include WCAG 2.0 is at CR. That require edit job on techniques, have to reshuffle.
WC Issue I'm concerned about is checkpoint solutions. Ask HTML WG how going between versions has been for their implementations.
GR Doesn't make sense to me to move ATAG to 2.0, until WCAG is also to 2.0.
MK Since we are building views, one referencing WCAG 1.0 another referencing WCAG 2.0.
CMN My impression is that it is not stable.
WC WCAG Techniques also doing that, since have work to do still for WCAG 1.0.
CMN Wombat could become 1.x, refer to WCAG 1.0. We haven't done a detailed analysis, not much difference, hopefully just clearer. If you conform to 1.0 you'll conform to 1.x. To go public, have to go through IG review, another couple of months before out. In that time, we should work on techniques.
JT Yes, techniques.
DD Plan to release wombat as a recommendation?
CMN No plan, but a possibility. If in 6 months it has settled down, we have CR exit criteria, and WCAG 2.0 is going around in circles, then it might be worth putting out 1.1.
DD It is something W3C can do fairly easily. Ok to put out recommendation to replace a recommendation.
JT If we have to choose where to put our energies, if we have the draft out there, ... if we are simply working on techniques it is a lot of group energy. It would be great to have a mechanism to move forward or energy to put into it. How do we get that work done by more than one or two people?
DD If have a public working draft, shouldn't be too costly to move to Recommendation.
GR One thing we are doing with wombat, is addressing issues brought to us by developers.
CMN Should not put a lot of work into wombat for more than a couple of weeks. Playing with it for a few weeks, makes us think about techniques again. When we run out of steam with techniques, perhaps go back to the guidelines.
MK Yes, let it rest for a while.
CMN We are now rechartered. Later today I will change the charter link and people will have to read the charter and sign up for the group again. One requirement: as a participant you will do an authoring tool review each year.
GR Collaborative?
CMN that would be .5 each.
JT Good to have multiple reviews of tools to see differences between reviewers.
GR Consider list of existing tools, list of tools as reported by HTML writers group, then list of other tools. Hit those tools that are used.
CMN Basically, just review the tool you are familiar with.
MK Aolpress is a great tool for new learners, but not accessible. How do you deal with that? Tell how to get around it?
GR Get the evaluation, build test pages using it, then run them through tidy, a-prompt, etc. Show HTML Tidy before and after report.
CMN Tell them the accessible authoring process.
MK A toolbox consisting of x, y, z can get you there.
PJ Do we need to do these evaluations before or after CR?
CMN During the year.
PJ Does it have to document that a checkpoint has been implemented?
CMN separate piece of work. for CR must show implementation report. copy and paste from reviews.
PJ Make sure we have evaluation of some tool that implements the checkpoint.
CMN Evaluation is not a small commitment. Large part of work.
GR Graham used more about the tool by doing evaluation.
MK Good sanity check to do the reviews.
JT Two views: one for consumers, one for developers. comparison shopping for consumers.
CMN Major value is reality check and implementation experience.
MK Also important to make an effort to evaluate simple tools that beginning authors get started with.
JT WebCT could host in September in Vancouver.
CMN Perhaps MS host in September in Seattle.
JT One reason to not be in the states, is the cost.
DD Berlin in September
JT Back to november then?
CMN February: tech plenary in sophia, france.
Resolved: yes, take part in tech plenary.
CMN inclined to have next meeting in N. America. How does september work for folks?
JT Vancouver is much cheaper.
CMN November or September? After Thanksgiving (In N. America). Working on techniques.
GR If after thanksgiving, need time to travel after the weekend.
MK Can not say (september or november). First week of December is off.
Resolved: shoot for week of 10 September in Northwest America.
WC Trying for Australia?
CMN Many people won't make it, but expect to get sausage software. Expect talk about authoring and eval tools. Other WAI groups (WCAG, ER, PF, etc.). Expect techniques work, or how does it work. Who expect to go?
/* DD, CMN, WC raise hands */
CMN Not expecting serious AU tool meeting, but discussion of tools.
/* moment of silence for Len */
DD changes something?
JT How applies to ATAG. How ATAG deals with EARL Reports. Write evals in EARL.
MK Web page that produces EARL assertions.
DD Can be used to represent Web content, input or output to an authoring tool, could be used to represent eal of authoring tool
JT Put that as a technique (to process earl)?
CMN Don't recommend until stablizes, also covered by "use W3C techs" (if becomes a recommendation). Using to produce eval reports. Hack WART to produce.
GB How easy to generate human readable EARL output.
WC Can generate checklist or implementation report, once have results in EARL.
GB Show a more real-live example of EARL rather than simple?
CMN Ralph Swick presented about it yesterday. I will put that result out. Another one would be the WART tool.
Action WC: to add EARL-let to the EARL overview.
Resolved: EARL as technique for checking and repair, hack WART to use for ATAG and generate EARL.
Action and resolved GR editor for evaluation techniques for testing conformance (he volunteered! we all saw and heard it!)
JT Since not using ATAG to structure this, we are using WCAG. This document needs to come before the tool. It would be good to create structure of the tool and fill this in. Also avoid 1.0 vs 2.0.
GR Exactly, those are the design principles I want to follow.
Last Modified $Date: 2001/12/14 06:17:26 $