Agenda: how to link evaluation to document: Interleave evaluation results in source? Put evaluation in separate file and point into document via XPath? Via Line Number? Via added pseudo-id attribute?
MC The XPath pointing into would be preferred, the catch is that HTML does not require the tree nesting structure is required for using XPath. Therefore, can't use unless tool already modifying file to be more XHTML/XML like.
WL Why not just Tidy it up?
MC Depends on if the tool is performing a Tidy utility.
LK If do have Tidy file and the XML points to the Tidied file. Need to tie the Tidied file to the original.
MC If have sophisticated enough Tidy tool, could do that.
WL Doesn't Gerald's tool do that?
MC Don't think so. Have to look at it.
WL You can get parse view, all of the errors.
WC You mean the W3C HTML Validator.
LK Does it XHTML-ize something?
WL Doesn't change them, but gives you the errors.
MC Therefore 2 steps: tidy or not, if using XPath how is it pointing to it. One suggestion, add an id attribute, another is to point into it by position in doc tree. id is robust across instances. by position is not as robust because if document modified then tree positions may change. using id's involves rewriting code. it's less obnoxious to add an id attribute rather than custom elements. i'm interested in non-tool specific code.
WL Philosophical decision to Tidy code before we tool it?
MC Yes, except it's probably not a decision we will want to make. Let the individual toolmakers decide that.
LK It's the tool's business, but how do you inform the user?
CR If the document is contained w/in the evaluation doc so that it can be recreated as it was initially. Then you can pull out just the evaluation.
MC If it will be saved with those extra elements, I'm not sure that's what we want to do.
LK In PA it's a state regulation that state sites follow the W3C. We have to have verification of that.
WL It's not warrantless, in general you don't go on the web and modify their site. You're just annotating it. Unquestionably, it is best to Tidy it.
MC My response is always, "I wouldn't use that tool." I hate having my code messed with. I would love a tool to add the "alt" text, I don't want to see all this other stuff added to it.
LK If you like to deal with the HTML, if new id's added then you can search to them, if they change other pieces of tags, or removed closing tags, ... There is one class of errors that we can't mark this way, "invalid HTML." You can't document invalid HTML after you've transformed it.
DB The FrontPage folks took pains to not modify code.
WL This is off on the side.
DB That's what they would prefer.
MC Exception that using XPath requires changing the code if not XML.
WL Could be separate.
MC If you repair something you will need a pointer to the right place to do the repair. with XPath would have the pointer, but only to the modified file.
WL Here is ".original" and then ".copy" and that's what you modify. can then have a side by side comparison.
MC The original won't have repairs made to it.
WL Once you've gone through what you object, then you can say, "go ahead and change it."
DB It's fine if they are accepting it. "I accept this change." that's ok (by user "o.k.")
LK If the user accepts change to XHTML. What if you have a user who doesn't want it, then say sorry, can't use the tool?
WL Like grammar checker, don't have to spell a word like they request.
MC Double or nothing. either XML-ize and repair it for accessibility or do neither. The people who want to do one but not the other are not served by the tool.
WL If you want to change to XML, tool to do that. If want to do some accessibility fixes without doing that.
WC Not exactly all or nothing. Should depend on the author. You can do the evaluation but you don't have to modify the file or save the state info.
LK All alt-tags exist and correct, then someone changes the document tree. I've lost my alt-text checks. Better to have it be as robust as possible under editing of the pages and simple-id's does that.
WC If order changes but still have 5 images and file names are the same, then could you assume that the order change does not affect context the images are used in? Yes, should be as robust as possible but not everyone is going to accept that.
WL We must always consider "cry wolf." If we don't leave options.
MC We've come up with 2 general approaches: XPath using id or position, wrap XML tags in pieces of source.
LK Additional id attribute.
MC I aggregated that into XPath approach.
WC Two axes: XPath or wrap, separate set of files or not.
LK If you have those two set up in such a way that you can mechanically convert from one to another, then we're just talking about implementation. Can we map between them?
MC Agree can map between, in the XML approach mapping to the inline approach is harder. Another axis: one session or between sessions.
LK Important axis.
MC Xpath approach easier for cross sessions w/out custom markup in page, tradeoff if having XML-ized the original code.
LK Major dependency seems to be: who is doing the evaluation. In PA I can't require sites to stick the ID tags in there. On Monday, I make judgements, then they make changes, then I have to judge again. I want something that is robust under changes. That's if I'm an outsider. If it's my code, I would be most happy sticking in id's. Different users are best served with different methods.
MC I've had this discussion, part of the cost of this tool is that certain things be changed. The whole XPath approach only works for structural features. Those that work for content don't work. Chris' approach may work best here. With XPath all can do is point at the paragraph can't point to features. With Chris' could mark, "this is a front-loaded sentence."
LK You can't point to the 3rd word of the 2nd paragraph? e.g. you can't point to CDATA? Even saying that language changes, no way to point to that word.
MC Not unless there is a "span" element on that phrase.
LK Want to ask for an extension to XPath?
MC I assume someone working on.
WC At least it will point to that paragraph and can then say "these 3 words" and the person can look for those words.
LK If you have something annotated (like chris did) it seems you could process that to create separate document with XPath pointers as close as they can get.
WC Combining the approaches?
LK
WC Al had good questions about Chris' approach, overlap of tool assertion and original HTML.
MC Could say, "violation type1 = longdesc, type 2 = alt, etc." reduce nesting of error elements. use RDF.
LK Or you could nest them. Wrap error 1 around it, then error 2. Wouldn't matter how nest. Would be irrelevant semantically.
MC I'm seeing LK move towards saying "these 2 are equivalent" the trade offs are different. But there are trade-offs to either one. Source code will be modified. This is against the way current tools are working. There is no comment format, they do things internally. There is no trade-off in terms of modifying source. However, then can't share data with other tools. That is a broader description of what we're talking about.
CR Can we share the evaluation data with other tools? Do we want to come up with a common format? One tool evaluate another repair?
LK Or 2 do the evaluation.
MC And a 3rd do the repair.
LK They may duplicate or compliment each other. Could get a sum of evaluations.
MC We're wanting to answer, "yes" we can share data. trade off of modifying source in some way. If assume perfect world (everything in XHTML) be a non-issue. This be the case in 5 years? Perhaps be leading edge and adopt that viewpoint.
LK Even with XHTML we can't point into text strings and if the tree gets messed around we could add additional heuristics, but does that cover it?
WC Look at spectrum, the ideal (nested elements and XPath) to nothing stored at all. Figure out how it breaks down based on user preference.
LK If each element has a unique id, can XPath point into that element.
MC Yes.
LK Use XPath and say, "authors, if you voluntarily put these ids in your source and here is a tool that will do it for you, then you will have these additional features available when you use these other tools." We stick with XPath and we give authors the option.
WC Good to me.
MC That's how markup languages will be evolving anyway. Unique ids will be necessary. There may be any number of transforms it may have to go through. Adding inline elements is an extension of this approach.
WL How reduce human readability? Can you hide them?
MC Will be some gobbledy-gook. If looking for things, not sure you can hide.
WC Would be cool to see Bobby, A-prompt, and WAVE implement this and begin sharing data between them to see how works and what issues are.
MC We could prototype. I can't promise to get it done in the next few weeks, perhaps months.
LK Yes. The way the WAVE works now, it does something similar to put in extra tags in namespace. It visually marks up the original markup. It wraps things in spans and sticking in extra tags. If it were putting in abstract tags the output would be output ala Chris or Al (if i stuck in colons to make namespaces).
WC CR using suggested file format already?
CR We have a working version that we've been testing.
LK I could take that as an input and wind up with WAVE symbols.
CR Once you have the evaluation several ways you can present it. We've been thinking of presentation modules: pie chart, graph, etc. Then allow the user to select.
WC What about the other way, WAVE into A-prompt.
LK It's like screen scraping. An icon comes on, could do something that works backwards into a-prompt. Would be better for WAVE to internally create an annotated file then convert into WAVE-like presentation.
WC CR how do you feel about using XPath.
MC I learned it from the W3C spec. Have heard that xml.com has good stuff.
WC Also noticed new articles at webreview.com
Action CR: review XPath and XSLT documentation to see how/if a-prompt could use XPath and XSLT.
CR Very concerned about changing code and authors not using tools if code is modified. With embedded version, could use XSLT to produce a good report. Can you use XSLT with XPath.
MC Yes. XPath is an integral part of XSLT.
CR We can agree that working on this standard is a good thing.
MC Easier for us to do the export rather than import. Sounds like WAVE be the candidate to do initial import.
Action DB I'll try to get Lisa to talk to people in FrontPage and get feedback from them.
Resolved: We will prototype sharing of evaluation and repair data between WAVE, A-prompt, and Bobby.
MC Generic and non-technology specific and therefore not be implemented by the tool. Have to take techniques and line up against those rather than guidelines themselves.
WL In principal can say that the checkpoints are machine-checkable. Do they have the potential?
MC That sounds possible, although looking at the specific techniques will inform that better.
WL The crafting of techniques may be affected by the notion of if they can be machine-checkable.
LK In addition to deciding if they are machine-testable, if not, there are ways to write a page so its easier for human judgement. If I look at a page and different versions created by style sheets I can tell that the various versions are the same. If one graphical the other not I have to use eyeballs. So, not just focus on machine checkable but how easy it is for humans to check as well.
WL The current 2.1 says "use markup according to spec" is machine-checkable.
LK Depends on what "spec" means." if "passes the DTD" then yes, if "blockquote should not be used as quotes" then machine can't tell that.
WC Machine checkable: syntax, human: semantics.
/* discussion of classes and styles */
WL A great many of the 25 checkpoints can be tested by machine. A bit more-so than WCAG 1.0 because being more general....do not use mechanisms that interfere with navigation...bullets help this refresh, frames, etc.
LK Wearing our ER hats, should we recommend "do not use techniques that will make evaluation more difficult." or a meta-principal.
WC How test? what does that mean?
LK specific techniques: you have a site that is accessible via an alternative site. If it is the same but uses style sheets, easy to determine. however if two generated by cgi scripts one produces images of text the other uses text. That's hard to check. We identify practices that make it hard to evaluate.
WC Device independent authoring workshop was all about that. Can't exclude database.
LK If architect that so that presentation is one module at the end, then easier to verify. But if no modules in common, then hard to verify.
WL The original thing that LK proposed is a meta-guideline that the WCAG WG should keep in mind as they develop WCAG 2.0.
WCAG 2.0 Requirements document
Macromedia will be there. Macromedia accessibility.
Someone from CAST. No one from ATRC.
$Date: 2000/11/08 08:17:28 $ Wendy Chisholm