- From: Leonard R. Kasday <kasday@acm.org>
- Date: Thu, 05 Aug 1999 10:25:34 -0400
- To: w3c-wai-er-ig@w3.org
Minutes from July 28 teleconference. Thanks Gregory! ER-IG TELECONFERENCE 28 JULY 1999 Len Kasday, Chair Gregory J. Rosmaita, scribe present: Harvey Bingham (HB) Dan Berk (DB) Michael Cooper, CAST (MC) Daniel Dardailler (DD) Len Kasday (LK) Brian Matheny, CAST (BM) Chris Ridpath (CR) Gregory J. Rosmaita (GJR) William Loughburough (WL) LK: first item: review of agenda: main thrust of the agenda is the discussion of the techniques themselves, CR has asked for discussion of timelines; don't know if we want to have implementation discussion now--perhaps at the end of the review process--may need to recruit outsiders for assistance in implementation; any other issues? GROUP: NO LK: sent out mail on Monday via ER list, comments on GLs; could just go through doc step-by-step, but first, want people to highlight issues that stand out in their minds CR: don't know if we should go through techniques one-by-one, as there are 37 already, and could easily expand to 40 or 50; if go through one by one could take too much time--want to set up process to go through them via email and have periodic calls to resolve issues; still, if the doc does grow to 40 or 50 techniques, even if resolve 4 or 5 a meeting, review could take months // WL joins LK: proposal: discuss individual techniques via email ACCEPTED WITH NO OBJECTIONS LK: what sort of timeline are you looking at? if went through checkpoints one by one, should we go through them in the current order, or should we have a meta-review with global comments first? CR: if tackle P1s first, rest will fall into place LK: resolved: review global issues first, priority 1 issues second, follow with review of other issues; reserve last 20 minutes of telecon for process issues--next meeting, next steps, etc.) WL: is Daniel joining? LK: said he would, but was ill during yesterday's CG call, so I'm not sure WL: DD sent mail subject "MIT Bridge just rings" stating that his phone just keeps ringing and ringing when calling MIT bridge LK: could someone perhaps patch him in? CR: DD replied to email stating we are here on MIT bridge LK: did he give number where can be reached? CR: no LK: email him and ask him where can be reached; need someone to patch him through CR: DD suggests trying 1 617 252 7000 (Tobin bridge) LK: adjourn to Tobin bridge // all leave // all rejoin on Tobin, plus DD DD: thought problems were due to my calling from France, but spoke with someone at MIT who couldn't reach the MIT bridge either LK: review of participants (see participant list); reiteration of agenda: go through global issues first, then go through P1s, at 20 minutes left will tackle process issues--where do we go from here? LK: global comments? DD: posted message about an hour ago about adding section to top--lots of editorial stuff--no brainers, really, provided CR is ok with edits; would like to see doc explain structure of each checkpoint or sub-checkpoint; need consistency from point to point CR: sensible suggestion DD: use sectioning--probably down to H4 or H5; better structure makes an even stronger doc WL: mention AU GLs in places where appropriate LK: global content comment: as is currently drafted CR's doc addresses things that can be automatically checked--need ways to help people manually check things; example: tool should display ALT text alongside pictures so as to allow user to quickly eyeball whether ALT text makes contextual sense; obviously, visually-oriented, but could work on that; similarly, if have APPLET, should put in alternative code-having the APPLET and alternative content side by side will facilitate quick review WL: what does APPLET look like? LK: could have APPLET that is organizational chart--when click on someone on chart, takes coordinates and acts on them WL: would you see the APPLET or the results? LK: would see APPLET function WL: would you see the APPLET code? LK: yes, plus whatever code is in there before the </APPLET> for browsers that don't support APPLETS; could do same for OBJECTS; is that in scope? CR: are you suggesting that even if images have ALT tool should display ALT so that author can take look and say, "this is OK" MC: would this be supplemental to other checks? LK: yes CR: user could then run through page and compare all alternative content to their OBJECTs WL: isn't that 1.1A? CR: addresses what is missing, not for checking validity or comprehensibility of what has been done, what changes have been effected, etc. DD: additional functionality; going through existing ALT and double-checking; good for a tool, although would consider it an additional path CR: sounds like a nice tool to have; but more than what we are asking for here LK: suggesting that doc have spectrum of ALL things that ideally a tool would have; doesn't commit the first release of A-Prompt or whatever to have them all MC: when we went through implementation and tried to apply to BOBBY, came up with a lot of granularity; adding a manual check item is another sub-category of the techniques; for each possible validation technique for ALT, for example, we had to create new application to address discrete issues-ended up with 97! DD: example? BM: out of 1.1.A developed 12 different applications, each associated with a unique error message; each error message is a different application of that technique LK: as far as UI concerned, is that consistent with seeing web page with images and all ALT and warnings next to it? BM: envisioning that you would step through for each technique; application 1 would check if alt text exists--if doesn't, then displays error message; if ALT content is there, checks to ascertain if it is too long; if it is judged too long, displays appropriate error message, etc.; so, the tool would step through the techniques one-by-one until you an error is discerned--if get through without errors, then could have ALT content displayed side-by-side LK: as user want to see what is there; don't want to be stopped by what the tool considers is too long an ALT text--want to see what the supposed offending ALT text is MC: additional algorithms need to be added, then; that is a different issue DB: general technique, to check for ALT, is specific enough; all ways of checking embedded in tool, not necessarily part of suggestions for how to implement MC: should be addressed in prologue/preamble rather than in technique LK: BOBBY then has more applications than those that appear in CR's doc? BM: 97 applications running under BOBBY; took original BOBBY GLs, and fit them under CR's listed techniques; have alerted CR to those we have developed but which he hasn't listed LK: please post to ER list BM & MC: ok WL: someone will have to lay down the law on ALT text-what is acceptable and what is not--there has been a raging debate for years now, it's time for the WAI/W3C to state what is acceptable and what isn't LK: I have a summary of what the consensus is; have already forwarded it to WCAG people, whom the WAI CG has identified as responsible for addressing issue in techniques doc WL: think WAI CG has to make a definitive statement ACTION ITEM: Len bring up issue of what are acceptable ALT-texting methods with WAI CG BM: background? LK: is ALT="" valid? is ALT=" " valid? [scribe's note: in the first example, there is no content and no space between the quotation marks; in the second example, there is a space between the quotation marks -- end of note] When we come up with issues, those are WCAG issues, and have been forwarding them onto them; something agreed upon in WAI CG that feedback should go to WCAG MC: there should be a message brought up by the tool in either case WL: should just lay down the law, whatever it is LK: will get decision from WAI CG HB: unfortunate coupling of ALT and LONGDESC; if one is present, BOBBY asks if other should be present; if ALT="" or ALT=" ", and there is a LONGDESC, is that ok? MC: BOBBY checks separately for ALT and LONGDESC--presence of one doesn't affect the other; would like to incorporate more sophisticated heuristics; perhaps, if ALT too long, suggest that author use LONGDESC BM: should also check if ALT too short HB: want a definition of what is too long and what is too short MC:: BOBBY checks for length of character string DB: can't always determine whether ALT or LONGDESC is more appropriate based on image's file size GJR: bigger problem is that display of alternative context is browser specific; some browsers don't wrap alt text, so even if it is in the doc source, it may not fully be exposed by certain browsers--UA issue, I guess, to mandate that browsers allow for expansion of alt text that is longer than the image area it represents DD: not sure there is a minimum--W3C logo is "W3C Logo" and that is that, no matter how large the image is in terms of bytes LK: I have a global global comment: we need to be careful of instilling too many false alarms in tools; have something that shows image and alt text and longdesc together--if asks if all info is there, that is sufficient; wouldn't like to hear if too long or too short--can tell from context whether it is effective or not; too many checks leads to the tool crying wolf; concerned about that; seems that if want algorithms, should experiment with them before releasing them to public WL: guidelines for the guidelines? LK: well, yes; don't want important issues lost in sea of verbiage BM: could be suggestion--some browsers don't allow ALT to wrap, etc. HB: that is something that goes stale after a while as browsers change, too LK: is a need for "super" warnings, such as a "by the way" comment or "more info" button; from a UI point of view, that simply entails having a switch for more or less detail GJR: what's needed is a user-configurable schedule BM: BOBBY looking into that MC: there is a need for different types of reports for different types of users; could be more than one set of descriptions slash commentaries presented to the user LK: gets back to another point: for each technique, there is suggested language for error messages WL: is this doc intended to do for people designing ER software what AU GLs do for authoring tool manufacturers? what is target audience? LK: developers, initially--AU GLs has requirements, this is a bunch of suggestions CR: I see it as an implementation of the WCAG--tool needs to check all relevant checkpoints; for example, WCAG say images should have ALT text MC: thinking about how BOBBY and A-PROMPT could work together; need common implementation LK: when you say implementation, do you mean that underlying software has something in common? CR: common set of criteria, underlying software different MC: now that WCAG are a recommendation, we have a firm set of checkpoints to check-allows us to fine-tune BOBBY, rather than drastically change it, based on WCAG LK: ideally, the applications that are in BOBBY, would you like to see them become part of this doc? CR: yep MC: based on document; use them to apply to BOBBY's internal functionality; if not represented in techniques, should not be in BOBBY; needed to create multiple apps to check down levels CR: if BOBBY is checking for ALT that is too long using a certain measurement, I want to make sure that that A-PROMPT looks for the same length of string before issuing error LK: should that be in this document? CR: yes MC: yes WL: are there any provisions for a human to be involved? should we have automated, semi-automated, and manual checks? MC: as I see it, there are some things that will always have to be manually checked; technique would be simply "ask the user"; beginning to think that there should be manual checks for all automated checks; how does user interact with tool? should be addressed in introduction or prologue CR: are some things that will need human intervention, but automated tool provides basis for analysis, but we still want a human to check the output after automated processes are run BM: could automate check for common suffixes, such as GIF or JPG, and if automated check shows that that the ALT text is simply comprised of a filename and/or byte size, could suggest to user that that is not going to be sufficient, and ask for valid ALT text CR: could easily build in manual checks to BOBBY and APROMPT; Michael and Brian, let's talk after this call to work something out LK: tool should not only say "these ALT text strings are suspicious" but should helps you fix it, by, for example, searching for other instances where the un-ALT-texted image does have ALT text, and suggesting that it be reused, or checking as GJR mentioned the TITLE of the document to which an un-ALT-texted graphical link points and using that as the suggested ALT text MC: there are some that will never be able to be automated--checkpoint 13, for example: "provide clear navigation"--machine not even going to be able to make a guess--need a technique there that says "ask the user" WL: could use side-by-side scenario Len suggested for this, too MC: yes, but need a formal technique in the document HB: as a user, I get annoyed at being asked by the tool "is this clear?" at every instance--would want some sort of algorithms that would learn-as-I-go, so that I can answer a question once and then move on to the next issue BM: trick is how much info to display; expert mode versus novice mode LK: once get to the higher numbered techniques, starting at 9 or 10, gets increasingly hard to automate; might be some ways of helping user check things; there are currently some site managers that will generate a site map, showing what is linked to what WL: have more argument with the 13 level checkpoints claiming that they can't be machine checked; machine check could be basis for human check LK: could algorithmically look for site map--page that has links to all other pages MC: what about an image map? LK: still has links MC: right, would flag if doesn't, but there are different levels of difficulty involved in checking a single page and checking multiple pages; need to discriminate between checking one page and checking multiple pages-algorithms may have to be different LK: agree--need distinction; for example, have tool compare ALT text across pages to ensure consistency MC: BOBBY or APROMPT would have to ask if user wants to check a page or a site; downloadable BOBBY can check all docs in a folder or in a domain; should be dependent upon the user WL: 13.4 -- " Use navigation mechanisms in a consistent manner " -- in a certain sense it can't be machine checked, but consistency from page to page can be machine checked LK: so, if I have a menu that I want to be on the bottom of every page, I could ask "tell me if this is on bottom of every page?" MC: how would it know where the bottom of the page is? LK: could ask: does this set of links appear on all pages? WL: and that the set of links that do appear are there are consistent from page to page HB: sounds like a repair, not an eval tool WL: repair tool needs to function as an eval tool first! LK: is there consensus that we should add to this document ways to help people do manual check, for example ALT and OBJECT side by side HB, DD, WL, LK, DB: yes GJR: yes, but need to come up with non-visual/graphical equivalent MC: yes, but should be in preamble, not in techniques, model on WCAG WL: these are GLs for developers LK: Bill's right-- why not have them in techniques? MC: ok CR: ok LK: should we address site level concerns? doesn't currently have site-level checks? WL: is there going to be an intro to this doc? CR: could be WL: well, then, if we say "avoid using hyperlink text such as 'click here'", we can also say "avoid crying wolf!"--when I apply BOBBY to several sites, I get tired of seeing all of the suggested checks--tool should learn as it processes, so that it knows what I have already done and what I am looking for CR: do you want the tool to keep some sort of history? GJR: use the spell checker model--ignore what i tell you to ignore, let me define exceptions, etc. WL: I for one don't want to hear about missing LONGDESC until LONGDESC is supported by browsers! CR: these are all good suggestions, bur are they beyond scope of doc? WL: that's why need to say in an intro "when implementing, consider the user, as much as the WCAG" HB: I don't learn anything by being reminded of things I don't want to know about, and that could lead to the tool being ignored CR: would someone like to draft an intro? WL: mine would be too wordy LK: someone else can edit/tersify it ACTION ITEM: WL will write an introduction and post to ER list for review CR: is it a good idea to post a draft on the web, discuss technique by technique via email, then take action at teleconferences? if we are going to roll all 97 of BOBBY's applications into the techniques, such a review could take 2 years! WL: some of them are unassailable LK: process issue: don't start 97 threads! one thread for each checkpoint; start with a general thread, but if have a lot to say about one item, then thread it off MC: one thread for each major group; don't want posts to the list to be too large, or no one will read them! LK: need a logical breakdown CR: have list of applications from CAST--can move them into my techniques document so as to provide a basis for review HB: include any qualifications you may have on them CR: will put them in, can argue about numbers later; will also implement DD's suggestions on organization LK: for stuff that needs manual intervention, you might break those items out as separate items within each technique CR: 2 different things: 1 checking to see if something is either not there or is being implemented incorrectly; 2) checking to see if content is correct WL: need to guard against over-automation BM: lot of it has to do with way report is presented, we are reworking presentation of BOBBY's reports LK: for each checkpoint, have 1) title, 2) definition, 3) evaluation techniques, 4) suggested language, etc.; should break down evaluation techniques into automatic and "aids to manual" BM: keep consistency; just add preceding verbiage, i.e. "automated" or "manual" or "both" CR: would like to have a think about this before making changes; will work up a few demos to find out how would be integrated into the tool; need to develop configurable schedules and test flexibility LK: would like to just see rendered page, and next to any image missing ALT text an error, where there are errors have symbols telling why, and would like an edit field so can correct on-the-fly MC: can be a user option; first need to flag items as auto-check, manual check; or hybrid--then program can be configurable CR: good suggestion LK: been assuming man techniques will be done by people who are sighted--need some sort of comparison for blind; Gregory, how do you approach deconstructing inaccessible pages? GJR: one of the handiest tools is to use the W3C Validator's outline view to determine the document's existing structure or lack thereof-if no structure is revealed by the outline view, that is a definite clue that FONT is being used to simulate headers, so then one can search the document source for FONT, in order to manually convert those strings into appropriate level headers; ALT can be more problematic-there will always be some cases where a blind individual will need sighted assistance to confirm that the alternative content matches the image-but it is often easy to determine appropriate alternative content from the TITLE of the target doc (if is graphically defined hyperlink); or from context of page, etc. LK: what about framed sites without NOFRAMES? GJR: check them with Lynx, which gives me a list of FRAMES, identified either by alternative content-if exists-or by URL. once I identify the navigational frame, I grab its doc source, and put into NOFRAMES as an ordered or unordered list, with, perhaps some introductory material from the main or intro page; obviously, this calls for human intervention-even if process could be automated, would want to double-check manually; in any event, Lynx is the ideal tool for me to perform such work, because it is concerned only with structure and content, which is what I am trying to expose when I deconstruct and reconstruct a page or site. HB: sound like repair issues GJR: as WL pointed out earlier, one needs to evaluate, before one can repair MC: outline view does seem most effective way to check for structure LK: handy thing to plug into Checkpoint 13 WL: whole document going to be very influential on AUGL; lot of this stuff is going to be in AUGL LK: framed version and noframes version side-by-side; how would blind do it? GJR: will review CR's document with potential non-visual approaches in mind LK: only 20 minutes left in telecon, so let's move onto process issues; first, issue: should we have regularly scheduled telecons? WL: propose we meet every 2 weeks--as long as people are using the list and responding to suggestions that are posted there, we will have material to work with so as to make additions and changes HB: propose we cut the meeting to an hour LK: ok WL: need to keep CR's document updated, but that should be quick--no W3C boiler-plates, requirements, etc. to bother with LK: is 10:30 am EST a good time? BM & MC: CAST has staff meetings until 11 on Wednesdays DD: can't before 10am EST HB: Wednesday perhaps not best day-there are 2 other WG meetings: UA and AU WL: WCAG WG meets on Thursdays GJR: Fridays EO in A.M. and PF in P.M. LK: what about every other Monday at 10 A.M.? NO OBJECTIONS LK: ok, then-we will meet every other Monday at 10a.m. EST HB: better make sure there is an open bridge! DD: will check right now if there are conflicts-the earlier the better. Tobin and Longfellow bridges booked Mondays at 10-9 a.m. for an hour is fine RESOLVED: hourly meeting every other week from 9 to 10 AM (EST) LK: next meeting will be held on August 9; the following on August 23; September 6 is Labor Day-will have to discuss at later date whether will meet on September 6 or not LK: do we need to set a deadline slash timeline? WL: not a REC, so doesn't matter if make progress along a timeline, though we should try to keep up with the evolution of AU GLs LK: I need to put together a schedule of what items will be addressed in what order-- will post to list //UA members start appearing on Tobin Bridge //meeting adjourned; next meeting August 9, from 9 to 10 a.m.(EST) -------------------------------------------------------- He that lives on Hope, dies farting -- Benjamin Franklin, Poor Richard's Almanack, 1763 -------------------------------------------------------- Gregory J. Rosmaita <oedipus@hicom.net> President, WebMaster, & Minister of Propaganda, VICUG NYC <http://www.hicom.net/~oedipus/vicug/> -------------------------------------------------------- ------- Leonard R. Kasday, Ph.D. Universal Design Engineer, Institute on Disabilities/UAP, and Adjunct Professor, Electrical Engineering Temple University Ritter Hall Annex, Room 423, Philadelphia, PA 19122 kasday@acm.org (215) 204-2247 (voice) (800) 750-7428 (TTY)
Received on Thursday, 5 August 1999 10:22:53 UTC