Agenda published 20 October 2000.
LK 4 (ER) and 5 (PF) of December. How many will be able to make ER?
WL Not sure.
CR Not sure.
BM Can't be.
LK Someone else from CAST?
BM Someone from CAST should be.
DB Someone from MS should be there.
WC I'll be there.
WL Being a locus for tools should be explored. We have the tool list and we have looked at the ones on the list. We ought to aggressively seek tools whether we write them ourselves or cull them out of authoring.
WC One idea from Amsterdam was using scripting w/in existing authoring tools.
LK Not aware that there is a common interface. We might want to think about establishing a standard interface between authoring tools and evaluation and repair functionality. Instead of ad hoc interface for each tool we have something that applies across them. The obvious format is XML.
WL What would it look like to someone using it? Would it interfere with the nature of some tools?
WC CR have you dealt with?
CR Ideally, it would be tightly integrated. We're going to go with a button on a toolbar. It's not automatic but it is there as part of the process.
LK What's the interface (the API)?
CR It's a windows .DLL function call.
LK How does A-Prompt get access to the HTML.
CR Two ways: calling app can send chunks of HTML, or whole HTML file one line at a time, or a filename.
LK If it gives us a string (an entire file or file name) how does A-Prompt identify to the tool a problem? or does it tell the user?
CR It returns an error code to let the calling app know there is a problem, and another code (what the problem is).
LK What is the location code?
CR It describes the elements that contain problems. We don't identify the exact element. "There's an image here that's not ok" but not which image element it is.
LK What if you wanted to add that. How would you go about that?
CR We've been working on a Java-based tool, the one we talked about with CAST. We generate an XML document that contains the original HTML doc with accessibility issues marked up in it.
LK How does it mark the problems?
CR Uses new elements.
LK For example, you have an image w/missing alt-text.
CR It would mark that image element saying it has a problem, then give it a code saying what the problem is.
LK As far as marking up, you could add an attribute, nest in an element. What approach are you using?
CR New attributes.
Action CR: Send to the list the an explanation of how A-Prompt is using XML to store information about a file that has been checked (or in the process of being checked)
LK Could run through a variety of tools to create a net result with annotations from multiple tools. Then have to keep track of which tool said what?
DB What about original document in XML? Should be able to check that.
LK What kinds of things could take place in XML that would be an accessibility problem?
DB It has to contain certain things. Is it there? Is it there in the correct fashion?
WC Would depend on if the DTD or Schema is correct. Then becomes basic validation.
LK There are human tests.
WC Right. Like HTML, you can't automatically test everything.
LK You need to specify what requires human judgement. We need some way to say "this element requires human judgement" in terms of plain old english.
WC Are you saying that we should tell language developers to mark which elements or attributes require human judgement?
LK We need to expand the notion of schema.
WL Sounds like meta data.
WC A bit of a tangent, but in general we need a way to store information about elements that have been checked by humans.
LK We should try to apply to XML.
WC Question is does this group define a way to store info about files? Is that what we want to pursue? How would you do this for WAVE?
LK Have to put some markup in original. If you point to it, the pointers could break as file changes. Put an attribute like an id in each element. Then have a separate file that refers to ids. Maybe we should put down a set of requirements for what this will do. Like, in WCAG WG, they say "this is the goal." Then we can figure out the implementation.
LK Should we pursue this?
Resolved: We will answer the question, "how do we store information about files." We will find a way for tools to store information that can be used across tools.
BM Keeping the state as far as what has been tested. Determining when a reevaluation is necessary. Check sums and such.
WC What can we do to help tool developers most?
CR AERT is still important. We'll have to bug AU, but its important.
BM When we come to implementing we can always come up with exceptions. Biggest problem remains possible need for human evaluation. Lots that could be automatic if not for the 5% case, then everything becomes partial eval. Trying to increase the machine automatic evaluation.
LK Yes, do want to increase it, but should it all be machine-checked?
BM Ultimately you need to access it through a screen reader or speaking browser, say up front "this will check as much as possible" but let it do what it can. Recognize the limitations.
WC Is there a way to integrate screen readers with voice browser to encourage that?
LK If you have a pure text version, e.g. a page where images replaced with text. Is it necessary to listen to it?
WC May not be necessary to listen every time. Bells go off when someone sees an assistive technology demo. WAVE can show what order table cells are read, but it can't give the sense of how overwhelming it is to navigate through the actual words and content, links, etc.
LK Right. What about low vision?
BM Screen magnifier mode.
LK There was a page that looked fine until I increased the font size. One of the lines word wrapped. It made it invisible. Now that I've seen the case, I can incorporate it into the WAVE.
WC Perhaps a tool to simulate disabilities, a piece that will help with the human part of it.e.g., low vision, speech, etc. At WCAG F2F someone mentioned for cognitive disabilities, we could only display every 3rd word.
BM Cycle through the different views, integrate the tools.
LK Highlighting a particular part of it and see that selection in every view.
WL In the vain of machine-checkable vs. human-checkable WCAG is working on WCAG 2.0. It's only about 25 checkpoints. I wonder if some of us could go through and determine which are machine-checkable, which need heuristic analysis, and which need a human. E.g. "use consistency" there must be a way to evaluate consistency.
WC A couple things on the table, those who are currently developing tools, would you be able to commit some resources to develop or integrate tools?
CR and LK yes
BM likely
DB There are a couple people working on FrontPage, I'll check in with them.
LK Could you ask the people working on FrontPage, that if they were fed XML, could they do something in a WYSIWYG or source view?
DB Yes, they would be interested in working with tools from other places. There has been talk it hasn't gelled.
LK In terms of work items coming out of here, I'm willing to do that.
WC Good for all of us to do that and discuss next week. WCAG needs the feedback as to what is understandable.
WL Also, the wording will help us figure out if it is machine-checkable.
Action everyone: review WCAG 2.0 for machine-checkable checkpoints, discuss next week.
Resolved: develop a suite of tools to simulate disabilities to help humans evaluate content.
Action WC and LK: incorporate into charter.
HB Don't ignore XHTML, especially a couple items that had been dropped out.
WL They said an accident.
HB There is tagging that should help in our analysis.
WL I had HTML docs and made XHTML out of them. I used Tidy and the validator and by hand. The browser forgave me.
Action WL: send tool URL to LK. It's in beta.
WC What about the face to face? Plan development on tools. Anything specific to talk with PF about?
LK If put in an id specific for pointing to by an accessibility tool, that would have to go in XHTML, that would be PF.
WL We ought to start discussing the inclusion of RDF statements as a means of asserting that you have checked things. Then people can find who's working on this. There are RDF tools that let you put things in your documents. We ought to encourage them.
LK Would be good to get their opinions in advance of the meeting.
WL A tool in the toolkit will deal with indexing. The inclusion of accessibility and metadata is imperative.
HB I heard more than I expected about digital rights managements (at open e-book conference). The basic theme of the meeting was protect the jewels. Make sure we get royalties for everything. Everything encrypted. Tools can not be used to copy text. It will be difficult for many of us to counteract. Publishers are feeling that every copy be a royalty stream.
LK One implication is that, if the source is encoded form how can we stick tags in there?
WC Or even look at it?
LK In fairness, the fact that someone doesn't want everyone to read something they wrote makes sense. They want to get paid for their work.
HB The library of congress has the ability to distribute things to people.
WL Ideally they would like to have royalty every time someone read their book.
HB Section 508 will be released in November.
LK Different from NPRM?
HB They got 100's of comments. There will be differences.
WC Public info?
HB Yes.
$Date: 2000/11/08 08:17:28 $ Wendy Chisholm