- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Tue, 18 Jan 2000 13:12:17 -0500
- To: "Leonard R. Kasday" <kasday@acm.org>
- Cc: WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
aloha, len! using the corrected page: http://astro.temple.edu/~kasday/web_access/image_map.html i heard the following using JFW 3.50.25 and MSIE 5.01 (version 5.00.2919.6307) TEST ONE (Image Map in TABLE) 1A. "SpeakAll" mode north image map link south image map link east image map link west image map link graphic picture of a compass (Note: all AREAs were selectable via the keyboard) 2B. using JFW's Virtual PC cursor to move through the document in chunks, i heard the following when the first compass was encountered: image map link north image map link south image map link east image map link west graphic picture of a compass Note 1: i had to use the "MoveToNextBlock" keystroke (Control+DownArrow) to hear the ALT text for the graphic announced, which is consistent with block-level navigation, in that JFW perceived the MAP first, exposed whatever information it could, and then treated the image on which the MAP was overlaid as a separate block... (which is also consistent with the manner in which the image map is defined in the document source) Note2 : All AREAs were selectable via the keyboard TEST 2 (Image in a TABLE) 2A. SpeakAll Mode graphic select a direction... Note: Contrary to expectations (since, by default, JFW 3.5 is set to announce when one moves into a TABLE), the presence of the TABLE was not announced by JFW 3.5 2B. Manual Navigation graphic select a direction Note 1: No information about the presence of the LONGDESC revealed. Note 2: There was no indication that this was anything other than a graphic -- perhaps this is due to an inability on JFW's part to recognize the USEMAP attribute, or a failure to reuse the MAP information defined for the first image map... Note 3: Contrary to expectations (since, by default, JFW 3.5 is set to announce when one moves into a TABLE), the presence of the TABLE was not announced by JFW 3.5 Question 1: len, are you (or do you plan on) sharing the results of your tests with screen reader manufacturers? if, indeed, my diagnosis is correct, and JFW either mishandled, couldn't handle, or didn't recognize USEMAP, then Henter-Joyce (jaws@hj.com) needs to be alerted to that fact... likewise with the manufacturers of other screen readers... Question 2: it would also be of utility to add a SUMMARY to the TABLE enclosing the image map, such as: SUMMARY="This table contains an image map of a compass; select a direction by activating the area associated with it" especially if you plan on drawing your test suite to the attention of AT developers... TEST 3 (Image with ALT and LONGDESC) only the ALT text -- "balloons" -- was spoken using both types of navigation TEST 4 (Naked Image Map) 4A. SpeakAll graphic select a direction (Note: Only the ALT text defined for the image map was spoken, after which i heard: visited link Here's results documented in a thread in the WAI interest group 4B. Manual Navigation graphic select a direction Note: This behavior, again, suggests that JFW is either ignoring the USEMAP attribute as it walks the MSIE DOM tree, as it has already provided links for the areas, or that it doesn't recognize or know what to do with USEMAP END NOTES: 1. when using JFW 3.5's "List of Links" feature, only the following links were listed: Skip to image map 1 Skip to image map 2 Skip to image 3 Skip to image map 4 results (a thread in the WAI-IG list) North South East West Here's results documented in a thread in the WAI interest group results kasday@acm.org IconBazaar 2. len, i'd be interested in hearing what happens when one follows my suggested technique for exposing and activating LONGDESC until user agents provide such a mechanism -- viz., enclosing the image to be LONGDESCed in an anchor which points to the URI contained in the LONGDESC attribute... obviously, while this solution would not work with an image used as an image map, it would work with TEST 3, but then one would have to either elongate the ALT text, e.g. Balloons: A Long Description of this Graphic is Available or would be a referential pointer: Long Description of Image of Balloons of course, one could couple a brief description (using the ALT attribute in the IMG definition) with a functional pointer (using the TITLE attribute for the anchor which transforms the image into a hyperlink) <a href="longdescb.html" TITLE="Long Description of Image of Balloons" ><IMG WIDTH="32" HEIGHT="32" ALT="Balloons" LONGDESC=longdescb.html"" SRC="balloons.gif"></a> but then one confronts the problem of precedence -- when one encounters a graphically defined hyperlink, for which a TITLE has been defined _and_ which has been ALT-texted, using adaptive equipment, which takes precedence? will the information be reliably passed on to the user? when i tested out the snippet of source included above, JFW simply identified the image as a link and read the TITLE associated with it, ignoring the ALT text defined for the graphic... i was then able to load the LONGDESC page... while i thought the LONGDESC concise and informative, i would have liked to have heard the following, as well: 1. a TITLE containing the name of the graphic ("Long Description for Image of Balloons") 2. the name of the graphic (cited as full URI, in case the user wants to download it and get a second opinion) 3. a "back" mechanism that takes the user back from whence he or she came which are a few things that i attempt to incorporate in all of my LONGDESCs (most of which are accessible via the hyperlink kludge) -- check for example: http://www.hicom.net/~oedipus/duke.html or http://www.hicom.net/~oedipus/knife.html gregory. -------------------------------------------------------- He that lives on Hope, dies farting -- Benjamin Franklin, Poor Richard's Almanack, 1763 -------------------------------------------------------- Gregory J. Rosmaita <unagi69@concentric.net> WebMaster and Minister of Propaganda, VICUG NYC <http://www.hicom.net/~oedipus/vicug/index.html> --------------------------------------------------------
Received on Tuesday, 18 January 2000 13:03:37 UTC