July 28 Minutes

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