minutes from 18 sept telecon

available at:http://www.w3.org/WAI/ER/2000/09/18-minutes.html
  18 Sept 2000 ER WG telecon
Summary of action items, resolutions, open issues
·       Action WC: update AERT and WCAG Techniques with null vs. space 
alt-text issue that was resolved in ·    WCAG WG telecon from 15 June 2000.
·       Open issue: priorities for techniques is an interesting idea. 
Wonder if applies across the document. P1 less heuristics, P2 more 
heuristics, P3 all heuristics.
·       Resolved: Add to Technique 1.1.2 a future possibility re: research 
project to check image complexity. Move check for bullet and horizontal 
rule to the research project.
·       Action CR: make this edit.
·       Resolved: The checking APPLET for HTML is still an open issue to be 
discussed next week.
·       Action MC: Find where in spec caused confusion.
·       Action MC and CR: send notes about this issue to the list.
·       Regrets from HB For next 4 weeks.
·       Open issue: what are we going to do about http headers?

Participants
·       Harvey Bingham
·       Len Kasday
·       Chris Ridpath
·       Wendy Chisholm
·       William Loughborough
·       Michael Cooper
Regrets
·       Dick Brown

Agenda
Agenda sent 15 Sept 2000.

Update on WCAG
WC Debate as to who writes the easier to read versions, EO or WCAG.
LK Here in PA we say, "WCAG" rather than trying to interpret as the U.S. 
Goverment did. Will WCAG WG resolve any of our issues at the F2F?
WC No, focus is on next draft.
LK What about the alt-text for spacer images? still unresolved.
WC No, it's not. Was resolved at 15 June 2000 WCAG WG telecon.
Action WC: update AERT and WCAG Techniques with null vs. space alt-text 
issue that was resolved in WCAG WG telecon from 15 June 2000.
HB Expecting fallout from DIW workshop to affect WCAG?
WC Yes.
HB Likewise, will WCAG affect DIW?
WC Yes.
WC We're focusing on language.
LK What about scripts? Directly accessible scripts?
WL Anything in a script must itself be accessible. Imagine that what will 
happen when we divide the Techniques document it may have a section on scripts.
LK Direct accessible applies to IE and Jaws which can handle scripts.
WC Yes.
WL We have to remember that the new WCAG will mostly be the old WCAG. Most 
of what we are working on is at the level of wording at the top part and 
how its organized. It will clearly contain the same guidelines and 
checkpoints. The fundamental differences are in how you say what you are 
talking about.
WC Right.

Open Issue: O2 Checking for longdesc
WC How do we check if image is "complex"? Don't ask for longdesc for icons, 
logos, etc.,. (from open issues list).
LK Related question, when is alt-text too long? There are cases when don't 
need longdesc b/c can use longer alt-text than usual.
WL Trying to figure out when to prompt for longdesc?
LK Yes.
WC What kinds of automatic checks can we do to prompt for it.
WL When you put an image in, should be able to put in longdesc as well.
LK Is it fair to say, as far as WCAG is concerned, he could put as much 
alt-text in there as he wants.
WL Probably a violation within the tool, no more than 250 characters.
LK Length is up to author's judgement.
WC Right.
WL Do we have a feature built into a tool where someone can specifiy that 
Bobby leaves out....I don't want to hear that I could put a "name" after 
every "A."
MC It's tough in the evaluation tool context, tougher in repair tool.
WL My site is miniscule compared to others and I'm getting 2 pages worth of 
report.
LK You just ask once, and you can scan over (eyes or ears). Perhaps we can 
categorize false-positives. E.G, "here's some extra info." If grouped, the 
author could skip as a group. Or something like A-prompt, where dialog 
boxes pop up, the author could check something to avoid those.
WL There are a lot of those. Setting preferences by the person using the 
tool seems to be very useful. Deciding the parameters of those settings is 
more complicated. I would never like to reminded that I should put a title 
or name at every anchor point. However, if I was building something where I 
might leap in in various points I would want those.
WC What about longdesc?
WL It's the same kind of thing. 80% of people using browsers where not 
using it anyway. I'll just make my alt better.
WC What about d-link then? It's the interim solution.
MC But the problem is that d-link is visible, many folks won't use. If we 
could get longdesc, tool support would come quicker. It's less intrusive.
WL Yes, many would like to use longdesc. Disadvantage is that d-link is 
visible.
WC Ways around that, to hide it by using style sheets or transparent images.
WL Works great for people who are blind, but not for me. What if I use 
d-link to get more info on text?
WC Controversial. Not intended use.
LK What about title?
MC In IE title on most anything, when mouse over will pop-up.
LK How long does it stay up.
MC Not long.
WL I think it's possible to put an element there and open some text.
LK Could use DHTML. Back to longdesc. The overall question is, "do we want 
to have something that automatically selects whether longdesc is checked 
for?" Does it trigger on every image? Or, just say it one time, like in 
Bobby. Or do you want to trigger on certain conditions.
WL Or choice to do one both or either.
MC If we have heuristics, "this might be bullet, or horizontal rule" are 
candidates for not suggesting longdesc. Someone suggesting determining the 
complexity of the image. i.e., lots of differentiation between pixels.
LK On the other hand, if the philosophy of longdesc is information that is 
not essential that gives additional flavor...what if a whimsical page where 
bullets are fruit or skull and cross bones? Then longdesc would be the 
place to tell someone about it.
WL Longdesc enables different information for different audiences.
LK Is that longdesc or title.
WC I would really like a longdesc for charts, maps, etc. What can we do? 
Image size?
WL Depends on author.
WC Can we look for patterns similar to what was done with identifying 
patterns of bullets and horizontal rules.
WL Then what do with those?
WC We seem to have consensus that it is up to the author to decide which 
checks to do, but if a large site people may want help identifying which 
images might need a longdesc. It's up to the author to choose that check, 
but could be helpful.
WL If you take Struck and White, but to build a program that does this type 
of analysis, you end up with a lot of laughers. That's sort of what we're 
up against.
LK There are things that would be nice, we can't figure out how to do. For 
purposes of AERT, on the one hand we say, "this warning happens with all 
images, but you can turn it off. As a research project it would be useful 
to analyze images and patterns of images for longdesc."
WL Talk of R&D group.
LK they could grep our doc for "research project."
WC reads text from Technique 1.1.2. Then we just add toLK's suggestion for 
research project.
LK Strike exception for bullets and horizontal rules.
WL Agree. That is part of the research project.
LK It's up to the reader to decide if they want the whimsy or not.
CR I think we should leave in bullets and horizonatl rules, but if you get 
rid of no big deal.
WL On the blind lists that I read, some people would like to know the 
details of the page. For example at the water cooler they won't understand 
the jokes about the risque bullet that was used. It's not important to 
survival but to inclusion.
WC Bullets/HR part of "inclusion" charts are survival. If author only 
checking P1 then don't check for longdesc on bullets/HR. Add a note to this?
LK We have a value system, "essential information" vs "secondary." The page 
itself may not be essential to survival in the first place. If it's nothing 
but entertainment...I am uncomfortable creating a value system.
WC Yes, it sucks, but if we demand everything nothing will happen. Adding a 
description for everything will take time. Ideally, everyone will do 
everything, but that's not the case.
WL And you will be ridiculed.
LK If you can say in one place, "all of the bullets on this page are small 
gargoyles." Or a page that gives a general description of the site. Also 
cuts down on the tedium for the user.
WL Maybe need a longdesc of the style sheet.
MC Think of ABBR. Only put in once. A UA could create an offline set of 
expanded acronyms in the document and present them every time you come to 
them. You're saying if longdesc for a particular image source, it wouldn't 
be required for it ever again.
LK Sounds like an extension of what I'm saying. An interesting point.
WL Could also be metadata.
WC We are getting into standardizing authoring practises which is more of a 
WCAG thing.
LK Also, PF and HTML and metadata and UA.
WC We do seem to have agreement that we can edit the technique, as long as 
we don't get into assigning priorities for bullets and horizontal rules. We 
can put that off to the "research project."
LK Although, priorities for techniques is an interesting idea. Wonder if 
applies across the document. P1 less heuristics, P2 more heuristics, P3 all 
heuristics.
Open issue: priorities for techniques is an interesting idea. Wonder if 
applies across the document. P1 less heuristics, P2 more heuristics, P3 all 
heuristics.
Resolved: Add to Technique 1.1.2 a future possibility re: research project 
to check image complexity. Move check for bullet and horizontal rule to the 
research project.
Action CR: make this edit.

APPLET and OBJECT
WL OBJECT is still alive in XHTML 2. Had accidentally deleted.
HB They were hoping that textual description stuff would show up in SVG.
LK Since OBJECT way of including Non-w3c standards, they wanted to remove 
possibility of including non-w3c stuff.
WL no. there's other ways to get that stuff in. The main argument was that 
it had become too huge. Had too many attributes.
HB Object had that as the last of the alternatives, render as text.
LK APPLET still deprecated?
WC Then how include multimedia? Other option is EMBED but it is not part of 
any HTML spec. So, what would you use for Flash, etc? I guess SVG would be 
included with IMG?
MC I thought it wasn't being implemented.
WL No reason to drop.
LK Think in IE.
WC Possibly also communicator.
LK If innermost thing is text then backwards compatible.
MC I always put img with alt inside OBJECT.
WL So, what's the issue?
LK There were a couple of things here. If you have an object and it encloses
WC If the innermost thing is a static image and object is embedding the 
image, then need text in the content.
MC For backwards compatibility I usually use IMG w/alt, but agree that if 
image included w/alt-text then need the next in the content of OBJECT.
LK Saying that is preferable, WC?
WC Not preferable, possible.
LK If have applet, does it need alt?
MC CR and I discussed and concluded that we were confused which elements 
allow content, which allowed alt. Decided to check for alt or internal 
content and as long as had one or the other o.k.
Resolved: This is an open issue to be discussed next week.
Action MC: Find where in spec caused confusion.
Action MC and CR: send notes about this issue to the list.
Regrets from HB For next 4 weeks.

Other items
WL Anything to check http for refresh?
LK I have an action item to find out the situation.
Open issue: what are we going to do about http headers?

$Date: 2000/09/18 15:38:56 $ Wendy Chisholm


--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--