date: Tuesday, 19 October 1999
chair: Daniel Dardailler
scribe: Gregory J. Rosmaita
DD: Chris, I noticed that there aren't links back to WCAG from individual= =20 ERT techniques -- could you have at least the title link back to WCAG?
CR: ok, I could do that; the checkpoint name is taken right from WCAG,= but=20 I could put a link back to the original checkpoint
DD: it is redundant, but it may lead more people to read the= guidelines!
CR: still trying to get access to W3C/WAI web space in order to maintain= =20 and update the ERT document
DD: this is a problem; I promise you I will look into it yet again--maybe= =20 I can have Wendy nudge the systems guys at MIT now that she is there; I= can't=20 believe that it's taken over 3 months, and you still don't have access to= WAI=20 web space!
// meeting formally begins
DD: current meeting time and date (Tuesdays at 10am Boston time)=20 presents a real conflict for anyone in the WAI domain who is physically=20 located at MIT, such as Wendy and Charles McCathieNevile; conflicts=20 with a local meeting, which is also Tuesday at 10; we had discussed=20 moving the meeting to Monday originally, does anyone have a conflict=20 with Mondays at 10am Boston time?
CR: I would have to leave at 11
DD: should be able to pare the meeting down to 1 hour if we meet=20 weekly; if everyone is fine with the move, then we will next meet on=20 25 October (Monday) and decide whether or not to meet weekly on-list
// NO OBJECTIONS
Resolved: ER-IG telecons will be held every=20 Monday from 10 to 11am Boston time (at least for the next 2 weeks, and=20 possibly permanently)
DD: as for next week's meeting, we need to discuss the presentation=20 that Wendy will be doing as the WAI Highlight at the upcoming W3C=20 Advisory Committee (AC) Meeting; I probably should be the one doing the=20 presenting, but I will be traveling and presenting in Europe, and Wendy=20 has been brought onto the W3C/WAI team to do (amongst other things) this=20 type of thing, too; she will talk about current ER products as well as=20 Trace and U Toronto projects which have overlap with WAI work; so, we=20 need to meet before that meeting, which would mean that we (a) need to=20 meet next week, rather than skipping a week, and that (b) when we meet=20 next Monday we should discuss Wendy's presentation--the kind of things=20 she can demo; probable topics: the ERT document, the table linearizer,=20 report tool, etc.
DD: sent message to update work on Table Linearizer; moved homepage;= working on online method of running linearizer via a form interface; maybe= a Java interface, so don't have to type from command line; has anyone= looked at tablin homepage? any comments?
HB: if download Java source code, are there instructions on running= it?
DD: yes, but that is why I'm working with my student on getting an online= version of the linearizer up as soon as possible -- the idea is to make it= easier to use; from the lack of downloads and comments, my guess is that= people find the Java interface too hard to run; perhaps they don't have a= Java VM or they find the interface too hard
HB: approach CAST took with Bobby was something that worked on its own= without user having to be aware of underlying technology
GJR: people are put off by the word "source"; need a direct link= to README -- more people will download if they know what to expect and what= is needed to run it
DD: a README accompanies the distribution; available in source directory,= which is linked off of tablin home
GJR: link should point directly to the README file, so that people can= read it _before_ downloading
DD: right now there is a pointer to source directory which offers you to= download zip of source stuff or browse through source stuff; should move= README one step up so becomes more obvious and a direct link from Tablin= homepage
HB: leave in zipfile as well!
DD: please send other comments to the list
DD: on back burner for now; have a list of improvements to implement from= feedback received from ER-IG list; need to put a privacy statement on it= ASAP; W3C has a privacy activity -- way to exchange META data; been asking= me to produce a privacy statement that informs user what the collector= intends to do with data; basically, been thinking of a simple statement --= not something long -- to the effect that whatever you give us, we are going= to use it for X and Y (send mail to webmaster with your name if you give it= to us, will be archived and that is it -- no selling of names to third= parties, etc.; short and simple; my questions for the group are: should it= be added to report home page, or pointed at from last form page when we ask= for confirmation before sending the comment and archiving it? on the report= home page, there is some indication that the fourth step is where things= are going to happen; should privacy data be made available up front or when= we ask individual to commit? I'm leaning towards on the front
HB: had chat with David Clark while in Redmond for UA F2F; he is very= concerned about political risks about putting this stuff up -- corporation= could sue an individual for slander or libel; I'm adding some of my own= thoughts on this -- David's worry is that there are a lot of legal= ramifications that we haven't fully considered
DD: concern is for the reporter? that he or she will be potentially sued= for slander?
HB: out-of-the-blue evaluations could invoke the "we didn't design= for that audience and you have publicly defamed us" response
GJR: I think that the problem is more of the fear of such action by the= reporter, rather than any real threat of legal action by corporation
DD: I'm not sure what the relevant laws are in the U.S., but I do know= that it is easy to sue anyone over anything there!
GJR: to prove libel in the U.S. you need (1) a provable / patent= falsehood and (2) malice aforethought; which is why letters-to-the-editor= cannot be held as grounds for libel; need to couch privacy slash usage= statement in same legal terms as disclaimers that cover letters to the= editor -- pure expressions of opinion; should not be interpreted as= definitive; etc. -- run by the W3C legal minds and get their input -- the= W3C does have legal counsel, doesn't it?
DD: three legal staffs, as a matter of fact -- one at MIT, one at INRIA= and one at Keio; will check with MIT lawyers, since that is where server= that hosts report form is physically located
HB: when a site that has been identified by a reporter as inaccessible= fixes problem, old comment should be linked to revised or new comment;= negative review that is acted upon shouldn't be in the archives perpetually= without pointing to a re-review; want to link all reviews of same site= together
// WC joins and is welcomed by group
DD: that's a difficult issue -- and one which borders on heresy -- for= the purposes of reliability and a host of other good reasons, we're not= supposed to change the mail archive; body of message should not be changed,= but could try to work out something whereby surrounding of message (next in= thread, etc.) points to new review; would be convenient, I grant you, but= problematic; need to preserve integrity of mail archive; perhaps can do it= via searching mechanism;
REMINDER: meeting moves to Monday at 10 starting next= Monday (25 October)
DD: will draft privacy statement and put on home page of report form;=
GJR: link back to privacy policy on each page -- at least a link back to= privacy policy boilerplate on each step as a CYA move
DD: can do; make more obvious on first page, stick boilerplate on all= others
DD: Chris -- how often do you update the ERT document?
CR: haven't updated version hosted at W3C site for 3 weeks, because= haven't yet been given access
DD: send most recent revision to Len, me, or Wendy as zipfile, and we can= put it up; Wendy can bug systems people at MIT to get you access
WC: ok
DD: document on U Toronto site more current?
CR: no, been making changes locally and not updating so as to avoid= confusion
DD: remind us of schedule for first official release of document? = targeted 31 October, right, but guess we are going to slip?
CR: yes -- the main hold-up is that I haven't been getting a lot of= feedback from the ER IG list
DD: guess people are busy doing other things--I know that is true in my= case
GJR: timing unfortunate, with AU having just finished Last Call and= potentially going to PR on the twenty-fifth, and UA barreling towards a= Last Call target date of 29 October
CR: Daniel, will Wendy be able to help us out on this document?
WC: yes--what kind of help do you need?
CR: going through items one-by-one to review techniques; keep pushing on= list and trying to get comments
WC: would be interesting to get feedback not just from people on group= but from Implementers; do we have developers involved?
DD: have the Bobby staff; genesis of doc was to formalize techniques for= evaluation; started with eval only, but added repair aspect, because that= is what A-Prompt does, as well; provides advice to people implementing WCAG= evaluation tool or WCAG repair tool; goal being that we end up with a= consistent approach for ERTs; validate techniques and checkpoints in WCAG= in a uniform way and make sure they are implementable; some can only be= manually checked
CR: is supposed to be an implementation of the WCAG -- if go through and= implement them all, document at end should be Triple-A compliant
DD: when you say implement, what do you mean? just someone looking at= the source?
CR: yeah -- if implement all techniques, can tell if HTML doc complaint= with WCAG
DD: Checkpoints referred in ERT doc points to checkpoint in WCAG, but= what about subdivisions in ERT -- is numbering scheme specific to ERT or= are they reusing WCAG numbering system?
CR: numbering system same as WCAG, but lettering system unique to ERT;= gave bulleted lists and narrative techniques in WCAG techniques numbers
DD: subdivision of checkpoints?
WC: should be clear link between WCAG Tech doc and the ERT document
DD: that's my question -- techniques provided in this document should= probably be labeled "ERT Technique X.Y" so that it is clearly= differentiated from WCAG Techniques doc
WC: Techniques in WCAG document aren't labeled; in sections and= surrounded by prose; not enumerated, but that may change, because I think= it presents a usability problem; difficult to map from Checkpoints to= Techniques
DD: would like to see experience drafting ERT lead to a better WCAG= Techniques document -- ok, back to the agenda -- there are 3 checkpoints= on the table: Auto-Refresh, BLINK, and MARQUEE
DD: thinking 7.4 and 7.5 quite similar -- ability to stop refresh and= ability to stop redirect; is it only because they both use META? not= saying should bundle them as techniques are different -- for 7.5.A= (auto-refresh) looking at test file for both but they are not what I expect= to see for test files; problem for 7.4 is refresh -- there is a delay of X= seconds before page changes -- doesn't matter if same page or different= page -- may be same URI with different data; 7.5 is auto-redirect, which is= just a service to the user (page appears and disappears); test file for 7.4= is what I'm expecting when I look at source; when look at test file for 7.5= using the same thing -- is that a bug?
CR: let me take a look
DD: different in that it does a refresh after 60 seconds to a new URL,= but not reflecting a redirect that is 0
MC: looks like test files are set up correctly; not sure if language in= 7.4 is clear; should be talking about obscure refreshing
// WL joins
MC: third bullet questionable -- if see URL is a redirect page, if don't= is a refresh page
WC: 7.4 refers to scripts and applets as well -- such as stock quotes or= baseball scores
MC: don't think we though about those -- need to add technique to cover= those
WC: 7.5 only way know how to do is META on client side; don't know about= server side
BM: can use JavaScript to do it server side
CR: perhaps WC can help use fix 7.4.A then -- I know that the ERT deals= with scripts elsewhere, but obviously need to address them here, as= well
WC: ok; can talk to you offline about process
MC: would it make sense to add as 7.4.B -- from implementation point of= view, easier if separated?
WC: question word "remove"
DD: had same comment; need to indicate how people find problem and point= out how to do it correctly, not advocate removal; if there is META with= HTTP-EQUIV content is always going to refresh -- if not 0, then will happen= after a while
WC: really a user agent issue, but real issue is person needs to control= how quickly it is updated; allow them to step through it or setting a= longer time on refresh; author needs mechanism to control, until that time,= needs to be slower
DD: yes, is an "until user agents..." issue; problem because UAs= don't provide delay mechanism
MC: would it make sense in repair suggested language is to have ER tool= pop up with number of seconds that it will take to have page refreshed and= ask will this be long enough?
WC: how specific do we want to be in this doc? do we just want to alert= or provide mechanism?
GJR: discussed in detail at last telecon; GJR will send minutes directly= to WC and CR
ACTION GJR: send minutes from last telecon to WC, CR,= and DD
DD: problem you mention, Gregory, in case where META not supported, is= different problem when it is supported and people don't have enough time to= read content or AT doesn't have time to capture it
// GJR unminuted recap of Techniques discussed at
<http://www.w3.org/WAI/ER/IG/minutes/m092899.html>
DD: ok, so here are the problems we want to address: if META not= supported, no way to go there unless author supplies hyperlink with URI of= refresh or re-direct page; if META is supported, but delay is too short to= be read, user doesn't get info
MC: support for re-directs provided by scripting; current approach is= that Bobby won't be parsing scripts -- don't think A-Prompt does either --= another good reason to separate techniques, but scripting may not be as= easy to identify as it is when META is used
CR: reluctant to get into parsing scripts
DD: might need manual check for that; how do we express manual eval? do= we say "if there is a script, check for..."
MC: would be one big long list of things that would ask; if find script,= would ask all script related guidelines
CR: might have to ask them 10 things; should probably only ask 3 at a= time
// WL rejoins
MC: start-up help approach?
CR: yes, with some elements, have to ask an awful lot of things
DD: 7.4.A META refresh -- eval look for
<META HTTP-EQUIV=3D"Refresh"=
CONTENT=3D"10;url=3Dhttp://www.foo.com">
make sure value not 0; should we say "don't do it?" -- is that a= sufficient repair technique, or should we ask that they put URI in a= hyperlink in BODY of referring document as GJR suggested? ask them to use= a real redirect?
MC: don't know if in our scope to suggest repairs outside of page content= -- would be difficult for tool to verify
DD: I understand, but if there is an alternate mechanism, should be= suggested; should indicate where want user to go; also suggest in site= configuration that there is a redirect from old one to new one -- not a= repair strategy, but fixes 0 values; if there is a need to wait, then put= in BODY; think GL in WCAG says provide a delay
WL: should be author's choice
DD: who is author?
WL: whoever is using ERT
CR: yes, we just give them guidelines
WL: guidelines for people writing tool?
CR: yes, but ERT provides guidance to page authors
DD: repair technique for a repair tool; finds out that there is an= auto-refresh -- what are you supposed to do? not a pure redirect -- just= waits five minutes and then refreshes
WL: give them choices
DD: between?
WL: put up skip pause mechanism; wait longer, wait not at all
GJR: is this really necessary? it could be listed as one option, but the= simple solution is to advise the author to increase delay and provide= static link in BODY of referring page that points to target URI of refresh= -- tool could grab URI from META and pop up box asking "would you like= to place this in the body of the referring document as a hyperlink?" = then, even if the author doesn't add any explanatory prose, such as= "please update your bookmarks", "if your browser doesn't= support auto-refreshing..." -- or auto-redirection, depending on the= case -- "please use the following link to manually refresh this= page"; etc. the important thing is getting the author to include the= URI in the BODY in an actionable manner
CR: WCAG very specific -- "don't cause pages to auto-refresh" --= ERT should first suggest "take it out", then should ask for a= hyperlink using referred URI as hyperlink text if author chooses to= "keep in"
DD: is there only one technique, or are there more? can make things= blink using CSS, I think, or by using a script -- need to address;= evaluation: look for BLINK, is that the only suggested language? not that= they are not standard/valid HTML or that they cause problems for adaptive= equipment and for some PWDs?
CR: trying to get away from bringing everything back to PWDs -- want a= general usability tool
HB: telecon running overtime
DD: technique: remove BLINK; should we point to CSS if really want BLINK= mechanism that can be user over-ridden?
GJR: that could be an "advanced" option -- we should have an= intermediary step: if user chooses "No" when asked if wants to= remove BLINK, pop up explanation of interoperability, accessibility, and= usability problems posed by BLINK, noting that it is a bloody stupid thing= to use, but if author chooses "use BLINK anyway" then prompt user= to use CSS to achieve BLINK
DD: replace BLINK with STRONG or EM or use a SPAN should be first= step
DD: movement in page is a big problem, so should we say "don't have= any" and be done with it, or suggest repair strategies?
GJR: are we talking merely about use of the proprietary MARQUEE element,= or are we also talking about scrolling/marquee effects generated by scripts= and/or applets? for a blind user, such as myself, who is constantly= querying the status line for information about the document and the status= of the UA, if we are addressing scripts, then I think we need insert= verbiage about preserving the integrity of the status line -- maybe this is= more of a WCAG issue -- don't use scripts that obscure / take over the= status line
WL: not just blind users who are affected -- obscured status lines are a= pain for all
DD: if use big script bucket, then can put it there, but do we want to= address scripts that cause moving text in this technique?
WC: I would think "yes" auto-refresh is new info coming down the= pike, while moving text is reinforcing currently rendered info -- at least= that is what MARQUEE is generally used to do, or, rather, is intended to= do
DD: question is should we use with document or go back to WCAG and= generalize idea of moving text to include scripts and animated text; is= this changing the environment, or recycling content? anyway, repair= technique is "don't do it?" what browsers support MARQUEE
MC: Internet Explorer
DD: what does it do in NS?
HB: it is ignored
DD: repair suggest replace with STRONG
WC: did a Java applet that when moved to it with tab, pressing space bar= would pause it -- possible strategy for script
GJR: if using MARQUEE where structural markup should be used, use= structural markup instead (i.e. if using as H1 equivalent, replace MARQEE= with H1)
WL: don't think can force any particular alternative
DD: if short text, use STRONG or use CSS to put box around it; if text= really long and need scrolling, could suggest pointing to a separate page= with long text or use inline IFRAME with text embedded in page with= scrollable window, or is that overkill?
GJR: yes, I think it is overkill, as it opens up another Pandora's box --= repair strategy that suggested use of IFRAME would also need to address how= to make the IFRAME content accessible
DD: ok, so we can just suggest "don't do it"
Resolved: ERT should suggest that author not use= MARQUEE,=20 and offer to change content enclosed in MARQUEE with (1) STRONG or an=20 appropriate header level if text being used as a header; (2) use CSS to draw= =20 a box around the text enclosed in MARQUEE
// End of Agenda Items
CR: Daniel, I will send you an updated copy of the ERT document by the= end of the day
WC: Chris, I will talk with systems guys today to get permissions for you= to update yourself
CR: thanks, Wendy!
HB: Wendy, do you have a new email address?
WC: yes, <wendy@w3.org>
HB: I have a suggestion for the ER homepage -- please add names rather= than just list email addresses
CR: Brian Metheny not listed
DD: page and list of participants needs to be updated; will probably do= what I did for PF page -- list "members in good standing" and= "less active members"
// ALL LEAVE
// END OF MINUTES FOR 19 OCTOBER 1999 ER-IG TELECON