WAI Evaluation & Repair Interest Group Teleconference

date: Tuesday, 19 October 1999
chair: Daniel Dardailler
scribe: Gregory J. Rosmaita

Harvey Bingham (HB)
Michael Cooper (MC)
Wendy Chisholm (WC)
Daniel Dardailler (DD)
Brian Metheny (BM)
Chris Ridpath (CR)
Gregory J. Rosmaita (GJR)

Len Kasday (LK)


1) New meeting time
DD proposed Monday at 10am
next meeting Monday 25 October; following 1 November 1999

2) comments on Tablin planning

3) WAI report tool privacy statement


5) ERT 7.2.A (BLINK)

6) ERT 7.3.A (MARQUEE)



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


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

Topic 3: WAI report tool privacy statement

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

Topic 4: ERT 7.5.A (REDIRECT)

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 28 September telecon, consult:

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"

Topic 4: ERT 7.2.A (BLINK)

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

Resolved: Repair strategy will consist of the following= steps:
1) remove BLINK or replace with STRONG or EM
2) if author chooses "No" when prompted to replace BLINK, issue= a dialog containing an explanation of accessibility and usability problems= posed by BLINK
3) if author chooses "Use BLINK Anyway", prompt the user (or= automatically) use CSS to achieve blinking effect so that end user has= control over presentation
Scribe's note
Please refer to GJR's post to <w3c-wai-er-ig@w3.org>, archived= at:
for a more=20 detailed description of potential problems arising from this repair= strategy.=20 The reference for the CSS2 blink equivalent is:
// end scribe's note / resume minutes

Topic 6: ERT 7.3.A (MARQUEE)

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"