WAI Authoring Tool Guidelines Working Group
Date: Tuesday 6 June 2000
Time: 2:30pm - 4:00pm Boston time (1830Z - 2000Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the Recommendation dated 3 February, available at http://www.w3.org/TR/2000/REC-ATAG10-20000203. The latest techniques draft is dated 4 May March, available at http://www.w3.org/WAI/AU/WD-ATAG10-TECHS-20000504. The latest draft of the Accessibiltiy Evaluation and Repair Techniques is dated 15 March at http://www.w3.org/WAI/ER/IG/ert-20000315
JT We need to discuss how it is easiest to integrate the two documents. How do we distribute the workload? Are there common format structures to apply to both?
WC Did not resolve how to integrate but that ATAG has interface stuff, AERT also has example language. One possibility discussed but not resolved was to move example language from AERT to ATAG-techs. Others recollection?
CR That'show I remember it as well.
JT ATAG has a checkpoint that points to AERT.
HB not more than one source for this material. Perhaps details are in one document that are pointed to by both documents.
CMN A database format to generate the two documents. For ATAG we're generating techniques for a variety of tools. That approach in general would work well for us. Currently AERT is building this document and AU is not. We're here to discuss how we (AU) can provide input to AERT. Should we push off things like messages to the AU document. That would come back kind of funny. AU has techniques that are general. We aim to have real live examples, such as Bobby or Word, so that instead of providing abstract messages we provide real-live examples. Demonstrate them as examples of how it works in real life.
JT We all agree that we do not want to redundantly do the work. Arguments for the same text in both documents so that all the info that you need is in one document and because of ordering in the difference contexts.
GR The biggest point from the face2face was communication and collaboration between groups. One advantage that AU has over ER is developer input. This will help ensure that AERT algorithms are not developed in a vacuum.
HB ATAG-TECHS are primarily references to Amaya.
CMN That's the starting point.
JT Are you looking at the latest working draft?
HB From February.
JT Intention is to go beyond Amaya and to use samples of working code.
WL In terms of text from AERT appearing in ATAG-TECHS, we could use inline-hypertext.
CMN The approach at the moment is to point to AERT from ATAG-TECHS. One reason to look at other ways (generating multiple views), is that a developer could get a view of the ATAG that meets the needs of the developer (based on what type of took they are developing).
JT ATAG-TECHS wants to point to AERT and potentially flesh it out. Do we simply link to it? Put it in a database that we can both reference? From the ER perspective, how could AU WG contribute to AERT in a useful way?
WC AERT algorithms and ATAG are interface. perhaps the "example language" is not needed.
WL is the only use of AERT for evaluation?
CMN The AU developers coming from ATAG are a subset of AERT.
GR If we expect tools to do some things automatically, the authoring tool needs to do eval and repair on the fly.
JT Common set of techniques authored by ER WG that are applicable to ATAG Guideline 4. WC talk about the interface?
WC ATAG interface
CMN so you point to ATAG for interface stuff (interacting with the author), we point to AERT for the nuts and bolts for checking.
JT What do you think about CMN proposal for database.
CMN how is AERT generated?
WC scripts. Len and I have talked about using the schema and transforms that was developed by XML schema group.
CR AERT as database or document?
JT Goal for AU is to generate not just 2 documents, but various views. If in a database and modular chunks we can produce those views.
CMN Wendy and I will have to work together. The tools will be useful by all of the WAI guidelines groups. The goal is to produce multiple views.
JT Do you see that as a valuable thing for ER?
DB yes good idea.
HB agrees.
CR agrees.
/* everyone seems to agree */
CMN an organic process. How do we contribute to AERT? Where appropriate take part in the discussions?
CR We could use people to take a look at the document.
WC The link to developers and feedback is key.
@@Resolved: AU will review and contribute to AERT as applies to AU.
CR We're looking to get out a new version in the next few weeks and then another in a few months. Should we stick to that schedule?
/* yes */
WL Designing new ideas doesn't preclude releasing documents.
WC ER has a list of tools. AU has a list of tools. Very related. Let's combine. People could search for tools based on a variety of attributes of the tool: meets AERT automatic checks, conforms to Level A of ATAG, etc.
CMN RPMFind also uses metadata (RDF) and that's how we could store and search through metadata. WCAG has an RDF scheme for conformance. That info could be included as well. Then we could use that info in various places on the web.
WL a framework for working with resources.
JT making some of it sound automatic.
CMN bits that are not automatic: Rpm2html needs some modification to provide for our needs. Assessment of tools doesn't happen by magic - someone needs to collect a library of tools.
JT it would be a consumer tool? Help them find a tool for their needs?
CMN yep.
GR people are looking to us to do that. I get lots of message per week about what is the most accessible tool for someone who is blind or low vision. People are looking to us to provide information for personal decisions.
CMN WAI gets asked for that info. AU would like to say "this is the state of implementation in regards to ATAG."
WC Keeping it up to date long term....?
JT One strategy is to update objective information.
WC We discussed this in ER. Our ideal is for each release of a product, a manufacturer would use a web form to update the database.
GR we need to coordinate this with EO. What ER and AU needs to do is look at the requirements doc for WCAG 2.0. Particularly, audiences. We are addressing similar groups. It's not just developers, but purchasers, and a slew of others.
CMN PJ pointed out a while ago, that one of the most useful things to know about a review is "who did it."
PJ Also good to know if the product that's available or one they are working on. Internally track info like: Person, date, level. then "yes/no/planned". Of evaluations. There are debates about what constitutes Yes or No.
JT The questions need to be objective. One way around is to have them show an example within the evaluation. It does not leave an ambiguous yes.
CMN Examples will help developers figure out how to answer questions.
WC Needs to be as painless as possible.
CMN It is generally in the developers interest to claim that their tool is accessible. By thinking through it will help them think about it.
WC No doubt that it's a good exercise. But if people have to spend time to substantiate their claim, they won't do it.
JT It becomes a marketing tool. People will take the time.
CMN What do developers have to say. It's not from a lack of good will mostly a lack of how to interpret something if there are not examples.
JT We're talking about a database of tools and making it easy to find out info about the tools.
DB Is that a certification?
CMN We need to be clear that these are somebody's assessment and we don't provide guarantees.
JT The more we limit it (through examples) the less we have to assert it's someone's opinions. We may have a developer who evaluates their own product, we could then have someone else evaluate it.
WC Interesting issues with certification and marketing that we need to be aware of.
GR Whenever a WG member performs an evaluation, they need to give the developer a chance to respond. Likewise, users should respond to developers evals.
PJ who said it, multiple evaluations, what exactly was evaluated.
WC ER info is not based on conformance but general info about what functions tools provide.
@@CMN and WC pursue database technology.
JT we need a testing procedure in AU.
GR working on. have an item to do so.
CMN AU has been evaluating tools against ATAG. AERT is not a normative reference so there it is not possible to claim conformance. AERT is based on WCAG. A tool could claim that it meets requirements of WCAG. There is a secondary approach to conforming to AERT, not by fulfilling techniques but by producing content that conforms to WCAG. This tool fixes these problems in relation to WCAG. There is an RDF conformance scheme for the various WAI guidelines and a tool that can pull this info together. Perhaps ER should create a conformance evaluation tool. A test suite.
WC a test suite to evaluate tools?
CMN so that you could mark it off as you went.
CR we would like a set of test files to run through tools to see how they support AERT.
JT that's also important. CMN is getting at a process to test an authoring tool.
CMN In simplest form, a checklist of things to try. AU generates: here is how we determine if we conform or not. Integrating that into WART and produce RDF would be handy.
WC Not sure in our scope. Would like to take that back to ER WG for discussion.
CR agree.
@@WC take idea of other types of evaluation tools for ER. What exactly do we mean by evaluation? Does it include evaluation of tools or limited to evaluation of content?
GR Do tools actually work? As part of ER, I would hate to lose IG.
CMN AU and UA are not chartered to write code. On the other hand, it does say that we look for things that we need in software. I do think they meet the needs of ER in terms of a feedback loop.
WL As well as IG group. One of the tools that ER will not build is to evaluate evaluators. There's no tool for that. That's done by people.
HB ER charter does suggest deliverables for ease of use.
WC Currently in ER draft charter we state that WCAG WG must evaluate our tools to ensure we have interpreted WCAG correctly. Perhaps have a similar situation with AU and UA.
GR ER is drafting techniques for application of WCAG in mechanical process and that's what AU is doing. We're saying these are the guidelines, these are what the tools should do. What's the difference?
JT We're referencing them. This is a side issue. CMN said that we may wish to produce a tool to help evaluators evaluate authoring tools. WC has action item to take to ER WG. AU needs to look at the piece in our charter about producing the tool. The secondary issue is having a tool that evaluates the evaluation tool. We extended that to the ATAG document.
CMN The tool to evaluate specifications is called W3C Member review.
JT Other thoughts about tools that evaluate tools?
HB One thing that is useful was a group of people getting together to fill in a checklist. Could we get this info from the vendors.
JT We need an objective review process. Interrator reliability. It would be useful to gather examples. How do we make the conformance evaluation process foolproof?
CMN I don't think we have enough experience to answer the question. Let's do it and see what we learn.
JT We need a number of evaluations of any one tool to determine where the ambiguities and where we need to fix the process.
CMN run the next meeting at this time? first tuesday in july?
WC that's the 4th of July.
@@Resolved: We will meet consistently on Tuesdays rather than switching between Mondays (ER time) and Tuesdays (AU time).
JT When is our next meeting then?
WC monthly? Lots to do between now and then.
CMN good to keep in contact and refocusing on each others issues.
@@Resolved: Next joint meeting 11 July, same time same place. Next ER at regularly scheduled time (next Monday). Next AU at regularly scheduled time (next Tuesday).
Last Modified $Date: 2000/11/08 08:13:13 $