LK we've been focusing on ERT, but people have been using the existing tools list, so thought a general discussion would be good. there's a number of tools listed, they are slowly being described. Wendy's been putting in some. I've been trying to add comments. Do we have any general comments about the page? There are about 4 lines of text per tool.
WL as a page or in concept? do we have a means of maintaining the validity of our tools? tools have a habit of going out of date. if it becomes static it makes our effort look ugly. there should be selection criteria for inclusion.
HB all the people that have product on the list should be notified and should send updates to someone. make sure they don't feel it is grossly misdate. then they take some responsiblity for pointer to their work.
WL get reviews from people who have used the tools.
HB currently, the comments are unsigned. It assumes then that it is consensus of the group. every entry should have a version number of which version is being reviewed.
WC not necessarily a "review." have contacted NIST.
HB will find it difficult to contact everyone. therefore means for dropping.
WL these are subset of AU. AU influencing future directions. perhaps say that eval tools a subset of authoring tools. some authoring tools do these things.
HB right, XMetal won't let you deliver an invalid document.
WC people want to take some of the tools and contact the devlopers?
LK W3C is supposed to be a vendor-neutral, ok to make statements about?
WC i added a disclaimer.
WL "nor are these all of the tools."
@@WC add to the disclaimer that this is not an exhaustive list of the tools.
LK delorie didn't include the links in the image map.
HB let him know of this. you are reporting what it is on this date of this verison.
@@LK send note to delorie developer before adding info to the list of tools page.
HB "we would appreciate the input of authors of various tools."
WL whoever is adding stuff to the list, the new ones have this requirement.
HB or put in comment, "we have no way to respond back to this author."
WC hasn't been an issue yet.
LK put the responsibility solely in the hands of the developer. Web page where they could go, put in whatever text they want...a semi-automatic way, give them X words. gives them the responsibility for keeping it up to date.
WC we're going to get out of date because it won't get into everyone's publishing routine.
WL CSS is static and out of date, doesn't say anything about mozilla.
@@Resolution: let authors know what text we're going to include, and ask that they keep us up to date.
@@LK volunteered to review a few tools.
@@WC make link to exisiting tools list more prominent on the ER list.
LK need reviewer name, date?
WC date of inclusion or last update on our page. not subjective so don't need "reviewer" name.
LK do we put in 1 or 2 defects, since we highlight is that o.k.
WL ok by me. if somebody is concerned about the purpose of the tools they might be angry with us for not pointing it out.
WC that issue with WDG vs W3C HTML validator.
LK since we tell people what we're gonna say, we're more likely to work to get it right.
@@WL will look at the list of tools and see if i can take any.
LK Will everyone agree to take at least one tool off of the list?
HB yes.
WL yes 2 or three.
LK should have asked when more people on the call!
WL you can ask on the list.
@@LK will ask everyone on the list to write something for at least one of the tools.
WC so, fill in the info for each tool (list at the top of the page), e-mail to author and to the ER list, ask the author to send update to the ER list.
LK for description: it's major features and deficiencies.
WC Techniques for Accessibility Evaluation, Repair, and Transformation of Web Content
WC Techniques for Evaluation, Repair, and Transformation of Accessible Web Content
LK implies already accessible.
HB Tools for Accessibility Evaluation and Repair.
WL "Techniques for automatic implementation of the Web Content Accessibility Guidelines" says "implementation" implies repair and transform.
HB kidding ourselves - not automatic.
LK Tools to assist evaluating and improving web accessibility.
WL can't say tools, to differ from list of tools. therefore, techniques.Techniques for the tools themselves.
LK why techniques rather than guidelines.
WC guidelines seems to imply a level of conformance, techniques are ideas.
WL very heavy differentiation. therefore, shouldn't use the word guidelines.
LK techniques for automated and semi-automated evaluation and repair of Web accessibility
WL Web accessibility evaluation, repair, and transformation tool techniques
HB guidance to implementors
CR do we need transformation
WC be good to keep the ERT acronym. we have 3 t's to chose from.
LK ERT mean - Evaluation, repair and transformation: web accessibilty ERT tool techniques.
WL are these tool design techniques? since intended for tool designer?
WC techniques for evaluation, repair, and transformation of inaccessible Web content. Most support seems to be for, "Web accessibility evaluation, repair, and transformation tool techniques"
LK doesn't roll off the tongue.
WL transformation is subset of repair.
HB it's something that a user would invoke rather than author.
LK repair is a transformation tool that saves the result.
WL repair includes both. so we can drop transformation.
LK we're using the repair as something the author or the tool does to the page. it depends on who is using the tool - if author and part of the web site, then it has been repaired. if it's something the user is using it is transformation.
WL can't think of transformation tool that is not a repair tool.
LK so leave it off.
/* people agree that is fine */
LK so it becomes, "Web accessibility evaluation and repair tool techniques"
CR drop "tool"
/* no. then just become WCAG techniques. */
WC sounds good to me.
LK yep. good enough to put on the list? try to get general consensus?
@@resolved: the people on this call agree that "Techniques for Web accessibility evaluation and repair tools" and if someone wants to suggest something new and gather consensus.
HB reading some of the voice browser stuff, sometimes only have 36 characters to get the title across.
WC Techniques for Web accessibility ERTs is 37.
HB spell out ERT after.
WL but use ABBR or ACRONYM?
/* laughter */
WL like that something could be referred to as an "ERT"
At what point do we publish document? Can we publish with remaining open issues? If so what sorts of open issues may remain?
@@resolved: plan for publishing a public document: WC finish going through comments on my comments, then we all need to reread to ensure that WC didn't break anything. then send to IG let them review for 1 or 2 weeks, incorporate their comments, then become public. Therefore, we'll publish tomorrow review over the week and discuss at next week's meeting.
LK yes, a few open issues. not as much pressure on this document.
HB this is our understanding of how they have been implemented. do we attribute who has done it.
LK if we get into attributing credit, then you have to thorough technology search.
WL you can say, "for example."
LK my philosophy is that you don't want to upset those that you omit.
WL but there is no way for us to go through everyone of them.
LK that's what you have to do for a paper or grant.
WC leave open. as we contact people for the tools list, we could ask them to contribute examples to ERT. makes it stronger to have examples.
WL try to get as many as you can, may not get them all.
WC adopt the philosophy as we move forward. try to incorporate examples, if they exist. i guess a lot of them won't have examples. almost should combine the 2 documents.
HB like the 2 forms.
WC yes, 2 audiences. those who need tools, those who are creating tools.
HB for all of the techniques that say, "human intervention required" is part of the repair. therefore, not only for tool developers but users of the tools to help them repair their own sites.
LK on the human judgement issue, the tool that i've been working on should be available next week.
more discussion in intro of automated vis. manual checks, and requirement that user of tool be required to assert conformance to manual checks (recording those assertions is a different issue)
HB assertion is a "prove me wrong." if don't give guidelines for assertions they could say "sure."
WC e.g. of bobby, get report "congratulations" before really deserve.
WL yes, we need something like that. rather be nagged than get a premature congratulations.
CR suggesting that bobby do that. then have to do that for every file.
WC not suggesting major change to interface, just take the list of questions, put a checkbox, before get congratulations.
CR we have "next".
/* people agree that "next" is like a yes check box */
LK but some people may prefer a list of checks. it would be like a to do list. keep track of their progress. do you cross off each item as you come to it or have one checkbox at the top of the to do list. i just spent $200 to give me separate checkboxes.
WL we ought to have some real examples of this. to me, bobby started out easy to use, now it is less easy to use.
LK that's an interesting statement. what happened?
WL It has become feature-laden.
WC main question, is should it be it's own technique or should it be in the intro, or other suggestion?
WL it depends on what happens in real-life. also, depends on the user.
LK depends on how they are presented. if you have a wizard where you have a box telling you A, a box telling you B, etc. Then instead of having all of them in an order you can choose. for a beginner it would be good to be lead through things one at a time.
WL trying to register for a face2face meeting, you go through a 4 step process, but you have to go through an e-mail in between. there should be something somewhere that has usability ideas in it. we're talking about that. the interface.
LK there is the overall question of "do we want to require an assertive action by the user" whehter it's one thing or a bunch of things is a separate question. do we have consensus that the user must do something to get the go ahead.
WL that they have evaluated these things.
LK do we want some action from the user.
CR yes.
HB if doing the whole site, don't want to do one by one.
WL but still want to be reminded of stuff that not automatically done. but claim that have done the human part.
HB concerned about how much good it would do.
LK would you agree it has to be there, tho?
HB yes.
WL ok. then the next level is to make suggestions about implementation. perhaps that is user configurable.
LK right, we don't want people doing a whole bunch of repetitive things.
@@Resolved: yes, include a technique to require an assertive action by the user for manual checks.
$Date: 2000/11/08 08:17:42 $ Wendy Chisholm