minutes from 30 October 2000

http://www.w3.org/WAI/ER/IG/2000/10/30-minutes.html

30 October 2000 ERT WG Telecon
Summary of action items and resolutions
·       Action CR: review XPath and XSLT documentation to see how/if 
a-prompt could use XPath and XSLT.
·       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.

Participants
·       Brian Matheny
·       Michael Cooper
·       Len Kasday
·       Chris Ridpath
·       William Loughborough
·       Wendy Chisholm
·       Dick Brown

Evaluation results in XML
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.

WCAG 2.0
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

Face to face
Macromedia will be there. Macromedia accessibility.
Someone from CAST. No one from ATRC.

$Date: 2000/10/30 16:48:50 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Monday, 30 October 2000 12:05:53 UTC