18 Sept 2000 ER WG telecon

Summary of action items, resolutions, open issues




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.


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/11/08 08:17:23 $ Wendy Chisholm