07 Feb 2000 ER telecon

Summary of action items and resolutions

Participants

Face 2 face

WC Daniel working on. CWI in Amsterdam can host. May 11 and 12 before WWW9. Who on the call can make those dates?

Will, Greg, Chris, Michael, Wendy, most likely Len.

ERT review

GR EO is doing a review. I am collating the comments: holes, usability issues, and good feedback. I'll send a pointer to the ER group. Len, people liked your talk at the Web for all and Judy will contact you about breaking that into a formal slides talk. Karl (GSA) looking for tool mock-ups. I told him to contact Chris.

LK part of that talk was a tool that I have discussed but is not publicly available. It stresses the human judgement side of ER. It shows page and alt attributes next to each image. It makes the tables visible. Puts numbers in cells to show order it will be read when linearized. There are uses for a sited person, they can get the info when you read it through a screen reader. The arrows and landmarks might be convenient for a user who is blind to communicate with a sighted user. I'll be making a Web script out of that. The talk will be an additional incentive.

WC when will the script be available?

LK promised by mid-March. Going to try for end of this month. re: EO comments, realize there are probably lots of details, is there a global comment?

GR also looked at existing tools page. most of the comments are about that. misleading title. more info about 1st class of tools than other 2. EO has not yet taken ERT in depth. Judy has mentioned bumping up the URL to the ER space, esp. the existing tools list. Have a parent doc, "how do i...?"

WC propose that EO should wait until this Friday draft for stability.

GR ok, then Len or Wendy should send a note to EO. Next EO meeting is the 18th.

@@LK send note today to EO to ask hold off on review of ERT until we send them the "all clear."

@@WC once publish next draft (that takes into account the clean up of review from Michael's and Len's comments), send EO note to let them know a stable draft is available.

Author indications that a warning has been checked

WC took it to AU before CG

LK took to CG, Al took to PF.

Checking for longdesc

WL that belongs under the heading of "human checks." the research effort is absurd.

GR one of the most effective strategies is that whenever you enter an image, the dialog box (homesite does this well), after the URI, it asks for alt and then longdesc. Therefore, asking simultaneously kill 2 birds with one stone. It brings out the difference.

WC What if an evaluation tool?

GR like tidy, for every table w/out a summary, gives a warning.

WC Chris and Michael? Ask every time? Weed out the ones that are obviously bullets?

WL what about purpose of thing being to create bullets?

LK user interface issue. a dialog box for every image, too much. a sighted user could go through a table and scan down. would be less burdensome than one dialog box at a time. if a blind user is not able to see the image, they may want to skip that. look at the alt-text to see if obviously bogus.

WL say have 20 images, w/out longdesc do you want to check them?

CR w/a-prompt - for each image that is not a bullet or HR we ask for longdesc then store in a file. if say, "no" we aren't going to ask them again. we show them one image at a time.

GR reuse and recycle. if 20 images on the page and 15 are identical.

MC that's more likely the case across a site than on a particular page.

LK can that approach be generalized? there are warnings that come up for every element. a more global approach would be useful.

WL Bobby tries to globalize. but it puts in so much detail.

MC we're talking about removing detail. "do any image on the page need a description?" can be a preference.

GR verbose vs. non-verbose preference.

MC down the line we'll store responses to questions.

LK this goes into user interface: in bobby, if 20 images get 20 hats. could get image for 1st had then dimmer or none for the rest.

MC great idea, but for the future. the hat code is not very revisable at this time.

WL "hat-less-ness" is a good alternative. This also applies to the "warning has been checked storage."

CR while we're on this. is there a better way than "the image is complex."

GR if the image can not be adequately described. you can have a simple image, a signature from the 15th century, but have to describe it. chris columbus had a very complex signature. the tool could mistake for purely decorative. the complexity of the context and the information the image conveys not the image itself.

WC reads from the NBA tape recording manual (pg 16, O, 1.).

@@WC include the NBA wording in the technique about longdesc.

CR still we have to do this for every image.

WL you have to train the author, she has to decide.

GR yes the text that WC read is good, including alt-text.

CR if you had a doc w/no text, large image, you could assume need longdesc. a lot of text, long alt-text, smaller image, could you get away with not prompting for longdesc?

GR if alt is too long, then prompt for longdesc. some browser will limit display of alt-text to height and width specified or image. need to keep terse.

CR that's the alt-text. it doesn't sound like a foolproof way to determine if image needs longdesc or not.

GR /* gives another example */

WC depends on context.

WL training vs artificial intelligence.

LK what percentage of users have access to the longdesc?

GR those that use latest version of HPR.

LK HPR is the only thing that gives it to you.

WC have a tool that converts longdesc to d-link. easy to go longdesc to d-link, not backwards. also more likely to get a designer to do.

LK then need these tools out there for people who don't have HPR.

GR another chicken and egg problem. the UA developers I've talked with ask how to do it? longdesc inline? mouseover and select? unwillingness to support until it is used by authors.

WL what about long batches of text? do we need a "showpic" - to show a picture to summarize text points.

GR in navigation bar, substitute arrow for text.

WC we're getting into WCAG issues.

W3C technologies

LK related issue: W3C technologies. if someone uses a .gif we should have them use .png. If you only have an image w/alt, it doesn't matter. .png can store text. Discussion to use that rather than alt-text or longdesc?

GR yes, discussion in AU WG. Can do it with .gif and .jpg. Many images have copyright info embedded in that manner. One strategy for prompting the author is to search the binary for a string of text and prompt the author to use that.

LK at this point, no discussion that the UA would have access to the text?

GR no. but, part of using W3C technologies would be use OBJECT over IMG. then provide cascade of formats.

LK but if all you have is an IMG element, then use .png instead of .gif. but .png is just as inaccessible as .gif i move to strike that out.

WL but .png might have text included.

GR we need to check .png conformance statement to see if they have one so we know what browsers are expected to expose.

LK but it's just a blank piece of text. it could have revision, author info, etc. we would need to parse it?

GR sounds like the info that can be associated via dublin core.

LK stick that into the png?

GR use png to create the rdf schema.

WC LK's question is, "is png better than gif?"

GR png is more compact.

LK there are lots of good reasons for using png, and other reasons against it (older browsers) i think we should worry about accessibility. if it doesn't do accessibility any good then we shoudln't ask for it. we can only ask for so much.

@@GR look into .png conformance.

MC agree, should only support as far as accessibility is increased. as a non-w3c organizaiton putting together a tool, don't want to say "don't use macromedia."

WC my intention was, "here are your options if you are looking for a more accessible solution..."

MC java the only substitute for flash?

WC smil.

GR svg animation.

LK who supports that?

GR experimental.

Check APPLET and OBJECT for any HTML element

LK have more than text in the content of APPLET, like links. e.g., headlines that scroll through. in the content, have text links that link to the headlines.

MC good idea. are both alt-text and embedded text required? think it should be one or the other.

WC think alt is like IMG and content like longdesc.

LK more of a guideline than tool question.

WC who wants to take to WCAG wg?

LK what is the official process?

WC I have been, but it would be good to get some other people doing this.

@@LK take quesiton to WCAG wg - "alt or text content of applet. if text in applet, also need 'alt'"

@@GR look into UA techniques. find out how suggesting to render.

LK alt in applet be invisible. applet is deprecated. that's why i argue against putting in there.

WL object has no provision for alt?

GR supposed to be in content.

MC check all nesting for text. thus, would be good to be consistent with object since object to replace applet.

WL context?

LK techniques had a technique to check for text. suggesting to test for HTML.

Valid "longdesc"

LK "longdesc" is a URI. currently it says, it should be a valid URI. but we want to point to something reasonable. if points to a gif it doesn't do any good. if points to cgi, could send nice html text or flash...no way from code to know what to do.

MC validate external resources? i thought we had decided not to do that this round.

LK it's not really external.

MC it complicates things. perhaps not have this this version.

LK we don't have a conformance. it's a bunch of recommendation.

MC level 1 check that valid URI, level 2 also check contents.

WL to preclude authors to abuse longdesc?

WC if not valid markup, then prompt.

LK but then have to retrieve it.what if cgi?

GR this was a thread during summer on WCAG.

WC yes, from PF. don't remember resolution.

GR technically external to the doc, yet it is internal since it represents something internal to understanding the document. if the tool can do it, let it.

LK do we have consensus or still issues? MC - why is it uncomfortable? It gets into a larger issue - implementation difficulty.

MC the discomfort, even tho no conformance statement would like to conform. We won't be able to follow all pointers.

WC but we aren't suggesting all, just longdesc.

MC but there are others, like "clearly identify target of each link" and frame source.

LK I can see how you are uncomfortable. What if there is another group who might want to do it, we wouldn't want to deny them the idea. Chris has been concerned about this too.

WL if i link to an inaccessible site, can i claim that mine is accessible?

LK GR's point is good.

GR nothing that says that UA might not display it in-line.

WL someone should be able to check if they want to go external or not.

LK once you make it recursive, just ask what depth do you want to follow.

WL yes, can carry to an extreme.

LK if you pick alta vista you verify the whole web.

WL some sites that contain other sites. Bobby does this. They let you select to off site or not. Longdesc be automatic.

GR brings in line with AU. Allow the author to choose conformance level, this is similar.

MC how can an author claim conformance. they can only claim what is under their control.

LK you don't just ask the depth of control, but how to constrain - e.g., pages that are inside the directory, sub-directories, etc. That puts a limit on external sites. The author can define what is "the site" and claim conformance on that. How machine-readable do we want that? One could say, "any page that has our logo on it."

@@Resolved:("valid londesc") it is desirable for the tool to follow links, whether interal or external, recursively apply guidelines to whatever depth the author wants. Longdesc is automatic.


$Date: 2000/11/08 08:17:43 $ Wendy Chisholm