9 August 1999 ER teleconference minutes

E&R TELECONFERENCE
Date: 9 August 1999
MIT Bridge +1 617 258 7910
        Chris Ridpath, chair
        Gregory J. Rosmaita, scribe

present:
     Michael Cooper, CAST (MC)
     Brian Matheny, CAST (BM)
     Chris Ridpath, U Toronto (CR)
     Gregory Rosmaita, VICUG NYC (GJR)

scribe's note: CR was first on the call; GJR then joined,
after calling the wrong bridge; a few minutes later, both BM
& MC joined; after a five minute wait, during which there
was some general discussion of work-in-progress, it was
mutually decided that a more formal discussion of the work
that CR, BM, and MC have been performing should be fully
documented by GJR, in the hope that minutes posted to the ER
list(s) would spur others into commenting upon the revised
document, as well as specific techniques;

MC: CAST is currently renaming and re-editing Bobby's
language

CR: is the language carved in stone?

MC: (laughs) no-it is an XML file!

GJR: could you post current language to list?

MC: I was going to post to the list, but didn't know if it
was ripe enough yet for discussion; I have a shortened
version--just the hierarchy-but am getting closer to an
implementation document, which I will post to the list if
others want me to do so

CR: I think it would be helpful to have a look at it

BM: is there an agenda for this meeting?

GJR: not that I am aware of, but since MC began detailing
his work, I've been taking notes, so why don't we just
continue this discussion, see what issues we can resolve and
what plans of action we can come up with, and then see what
reaction the other members have

CR: sounds fine to me.  let me comment upon the status of my
document-I have updated the implementation document with a
new structure that breaks the process into evaluation,
suggested language, and repair techniques; overall, it makes
it much easier to read; maybe could start off with a couple
of issues that could be easily resolved

MC: don't remember which

CR: there are 2 in particular: 1) notify user that complex
images need LONGDESC; 2) notify user that it is necessary to
identify the primary natural language of the document

MC: second shouldn't be contentious; make sure there is a
LANG attribute in the HTML tag; there is the possibility of
addressing the extra stuff that might be obtained via
content negotiation, but I'm not sure if that process is
within our scope - an ER program may not be able to detect
it; perhaps we could add something in the techniques about
checking it as a manual item: "if possible, use content
negotiation"

GJR: CR, has anyone contacted you about hosting your work-in-
progress in W3C webspace?  there was some discussion of it
during the 28 July AU WG telecon

CR: well, I thought I'd keep at UToronto until it gets
farther along, but I wouldn't mind at all if it was hosted,
or at least mirrored, in W3C space

GJR: will send minutes from 28 July AU telecon to CR - should
talk to Len, Daniel, or Charles McCathieNevile about moving
document to W3C space

CR: ok-I'd like to take a look at the AU minutes

// scribe's note: minutes of the 28 July AU telecon can be 
found at: http://www.w3.org/WAI/AU/telecon-28jul99

CR: getting back to the LANG attribute, should we post to list, 
stating that this is what we want to do?

MC: should make post as filled-out as we can

CR: let's discuss prompting the user to add LONGDESC

MC: how do we determine whether the image needs a LONGDESC?

CR: I think we need to prompt for a LONGDESC for every image
that isn't a bullet or rule

MC: would it be possible to have user input size info to
program-for example, this is an icon that doesn't need a
LONGDESC

CR: well, the ER tool should only ask the first time it
encounters the image, then ignore-it's only a nuisance once,
then!  if image has already been found and user has chosen
not to add LONGDESC, would not be prompted again

BM: same for a lot of other options

CR: so, need an automated check of the document--if uses
LONGDESC once, should recycle it?

GJR: depends upon the use of the image and the
implementation of LONGDESC by UAs-it may be necessary or
desirable to have a LONGDESC associated with an image once,
say to describe the seal of a university, and then not
again, although that is dependent upon the action of the
UA-I may not want a lot of excess verbiage being thrown at
me if I don't care what the image is, and merely hearing the
word "LONGDESC" or "Long Description of Graphic" over and
over most definitely falls into the "annoying" category-need
to ensure have that I as the user have control over the
timing and nature of the LONGDESC display, which points out
dependencies to both the UA and AU GLs.  I can also
conceptualize situations in which an author might use
different LONGDESCs for the same image-for example, if the
image recurs on a page which has a different natural
language declaration, LONGDESC URI should point to a long
description in the second language, etc.

CR: seems to me that ALT text could be different, but
description of image itself should be unvarying

MC: at CAST believe that the description of an image is
dependent upon the context in which it is being used; don't
necessarily want same description for every instance of
image-shouldn't always force to same URI

CR: well, an automatic tool would automatically link to one
LONGDESC, unless told otherwise

MC: reminds me discussion of ABBR element-HTML4 spec says
should only be used first time abbreviation occurs; not sure
about LONGDESC; as GJR pointed out, depends upon UA; would
default to prompting

CR: ok, I can do that

CR: next item I want to discuss is whether or not we can
come up with a list of criteria that automatically informs
the ER tool what images are being used as a bullet and what
images are being used as rule; haven't done any studies of
it, but figure if larger than 20x20, then I would argue that
the ER tool should not consider it a bullet

MC: good general rule; if bigger than 20 pixels, starting to
get to icon size; windows standard for an icon is 36 pixels
square; 20 is over half that-actually, pretty big

CR: should we start at 20 pix and see who complains

MC, BM, and GJR: agree

CR: what about images being used as substitutes for HR?

MC: I'd propose that 10 pixels be the max height for a rule;
what do others think?

BM: seen a few over 10 pix high

CR: we have a student intern who could go out, look at
sites, and see how large they are

BM: make sure he looks at a lot of images, and not just
rules and bullets-the more data we can gather, the better
the document and the resultant tools

MC: yes, and we can then come to the ER group and say "this
rule will apply to images of a certain size" - can consider
it part of ALT text discussion - put size info in an
appendix; bullet, rule, and icon size is a good starting
point

CR: old Mac size for an icon, I believe, was 32 square

MC: 32 and 36 square an icon, anything smaller probably a
bullet or HR; buttons also tend to be a standard size

CR: wonder if it is our role to figure these things out-if
these are standard sizes, couldn't the browser figure it
out?  if comes across a 36x36 couldn't it tell the user
"this is an icon"

GJR: but then the user still wouldn't know what the icon
symbolizes, what information it contains

CR: needs to be done during authoring process, then

BM: trying to detect images and say what they are is good,
but want to avoid nuisance prompts-only ask the user when
necessary

CR: does anyone know if this is being addressed by AU WG?

// unminuted discussion of AU working group led by GJR, who
was too busy flapping his gums to take notes; GJR offered to
be liaison between ER and AU groups; will post URI of
minutes and working draft to ER list //

BM: some of our document's checkpoints are very close to
being ready for approval; if a small group of us work on
them, we can get them pushed through and jump-start the
process of finalizing the document

MC: how long a period do we leave for comment after we post
something to the list?

BM: isn't there a legal term for approval by default?

CR: people are going to be the final test; will ultimately
have to revise ER tools based on user feedback

BM: yes, but want to minimize amount of revision necessary,
both to the tool and the document

CR: would like the document to be authoritative

BM: hoping that if get things done well, will be easier to
modify software based on feedback; document is definitely
crystallizing and getting much clearer; overall, I think it
is in pretty good shape

MC: well, we have 2 items to bring to list; don't see any
more offhand that could go, but do see a couple that might
be able to get there quickly; should ID those to bring to
list

CR: OK - I was thinking BLINK or MARQUEE should not be used
is ready

MC: should be a separate technique for each; think
checkpoints that fall under each - avoid BLINK under 7.2
Marquee under 7.3 with note that need supplemental technique
to cover movement ; 7.1.A would be split and moved to 7.2
and 7.3

CR: will you email me your comments?

MC: yes

CR: I'm concerned about the passivity of the suggested
language - "if missing ALT text." rather than "ALT text is
required for this image." - only implies that is missing, is
that better than - "You need ALT text-put some in"

GJR: get better response if you tell them "you need" or "you
must", rather than "something is missing" or "you should"

CR: who is going to figure out best way of doing it?

MC: the ER tool developers will have to be the lead on that;
we have a couple of other people at CAST, such as Sonja, who
could give feedback; want to make wording consistent over
techniques; passive voice approach not good anyway; would it
be helpful if we take another pass at it and pass along
comments to you?

CR: yes, definitely!

MC: agreed that approach want to take is geared towards
maximum user-friendliness and clarity

CR: yeah; also want to bring up something based on a comment
made at the last meeting about having more than one
mode-advanced and beginner; should the suggested language be
different for each?

MC: basic language and error messages should be the same;
extended explanation would be different-more detailed for
advanced; if even some of these things are truly only
understandable in expert mode (someone who understands HTML
source), how should we approach explanation; for example,
using lists to create indent-if someone doesn't know HTML
they won't have any basis for understanding the explanation;
this is going to be the problem with the higher level
checkpoints-they are problematic from an explanatory point-
of-view

CR: we could prepare a list; should also address device
independent functions, etc.

BM: need to be more in touch with AU tool users to find out
what would work for them-after all, that's why most of them
use an AU tool--so that they don't have to learn the markup
languages

MC: on BOBBY list get email all the time about ALT text-have
standard responses; one of the commonest questions is:
"FrontPage strips ALT text from my imagemap, and so I can't
get my page/site BOBBY approved--what do I do?  we suggest
they contact Microsoft, and, if they feel confident doing
it, editing the document source by hand in a plain text
editor

GJR: this is an issue that is addressed in AU GLs under such
checkpoints as: use W3C recs, don't remove any markup known
to promote accessibility; when encountering markup that the
AU tool doesn't recognize, do not remove without first
prompting the author; etc.  - would recommend that the ER
group check the AU GL working draft

// unminuted discussion of developer participation in AU WG
and receptiveness of developers to AU working drafts; again,
reason for no minutes is that scribe was leading discussion 
and responding to questions posed by others on the call //

MC: that gives us some guidance in what we are doing; we
should all keep up on the AU's work

CR: before next call, should we go to list with MARQUEE and
BLINK?

GJR: yes; with posting of minutes and specifics to list, we
are providing ER members with the opportunity to approach
the document from 2 levels-the meta level and the detailed
level, and hopefully, we can get feedback on both

MC: if posting to list, how can we demarcate what is a
request for review, and what is a request for approval?

BM: could vary subject line-APPROVAL REQUEST and REVIEW
REQUEST in caps

MC: will anyone respect them-or, rather, know what they mean
and respond accordingly?

GJR: if they read the minutes, they will! and, we'll have
the added benefit of discovering who actually reads the
minutes!

MC: ok-CR, lets you and BM and me work offline to get a
short list of things that can be addressed quickly together

CR: when come up with short list, put it out on mailing list

MC: will do

CR: are we finished?

BM: well, we're pretty much through our non-existent agenda!

// all leave 
--------------------------------------------------------
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/>
--------------------------------------------------------

Received on Monday, 9 August 1999 12:53:18 UTC