GNOME Bugzilla – Bug 518945
Orca has problems with certain imagemaps in FF3
Last modified: 2008-09-12 17:52:43 UTC
Steps to reproduce: 1. Navigate to Safeway.com 2. Tab among the items in the imagemap near the bottom of the page Expected results: We'd provide more meaningful information than just "link" Actual results: We just say link.
Here's part of an imagemap from radio4 at the bbc (see the "backwards.html" file in our test files): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <map name="atoz_map"> <area shape="rect" alt="z" coords="433,0,446,14" href="#z"> <area shape="rect" alt="y" coords="416,0,429,14" href="#y"> <area shape="rect" alt="x" coords="398,0,411,14" href="#x"> <area shape="rect" alt="w" coords="381,0,394,14" href="#w"> [...] </map> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's what Safeway gives us: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <map name="links"> <area alt="" coords="0,0,48,28" href="javascript:loadframesetpages('','http://www.vons.com','0','','')"> <area alt="" coords="48,30,124,0" href="javascript:loadframesetpages('','http://www.dominicks.com','0','','')"> <area alt="" coords="193,0,124,33" href="javascript:loadframesetpages('','http://www.randalls.com','0','','')"> [...] </map> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the first case, thanks to the proper use of alternative text, we present the right information. In the latter case, thanks to the intention provision of empty alternative text, we don't have anything to present. We do attempt to get the URI, but that fails. (And it seems to fail in both cases. Any brilliant ideas on how one obtains the URI for the items in an imagemap? If so, we could parse the javascript I suppose....) Suggestions welcome. Thanks!
Created attachment 106032 [details] the portion of the site with the offending imagemap I've attached the offending part of the site in case anyone wants to take a look at it in Accerciser (or anywhere else).
(In reply to comment #1) > Suggestions welcome. Thanks! Dear Safeway.com: I'd like to bring your attention to the W3C web content accessibility guidelines at http://www.w3.org/TR/WAI-WEBCONTENT/. I'd also offer the suggestion that you consider using tools x, y, and z, to check your content for accessibility. Signed, A potential customer
And P.S. please see: http://www.dralegal.org/cases/private_business/nfb_v_target.php ;-) But what I was hoping for is the answer to "how does one get the URI for the components in an imagemap?" question. ;-)
(In reply to comment #4) > But what I was hoping for is the answer to "how does one get the URI for the > components in an imagemap?" question. ;-) Oh, that part. If done right, something (the map?) should implement the Accessible Hyperlink interface, which should expose things like getNLinks, getLink, etc.
Created attachment 106046 [details] our "backwards" imagemap test (from bbc radio4)
Comment on attachment 106046 [details] our "backwards" imagemap test (from bbc radio4) ><HTML><HEAD> > ><TITLE>Backwards Stuff</TITLE> ></HEAD><BODY> ><P>This looks like A to Z, but it's really Z to A.</P> ><TABLE width="459" cellspacing="0" cellpadding="0" border="0"> ><TBODY> ><TR> ><TD>Test:</TD> ><TD class="atoz-rm"> ><MAP name="atoz_map"> ><AREA href="#z" coords="433,0,446,14" alt="z" shape="rect"/> ><AREA href="#y" coords="416,0,429,14" alt="y" shape="rect"/> ><AREA href="#x" coords="398,0,411,14" alt="x" shape="rect"/> ><AREA href="#w" coords="381,0,394,14" alt="w" shape="rect"/> ><AREA href="#v" coords="364,0,377,14" alt="v" shape="rect"/> ><AREA href="#u" coords="346,0,359,14" alt="u" shape="rect"/> ><AREA href="#t" coords="329,0,342,14" alt="t" shape="rect"/> ><AREA href="#s" coords="312,0,325,14" alt="s" shape="rect"/> ><AREA href="#r" coords="294,0,307,14" alt="r" shape="rect"/> ><AREA href="#q" coords="277,0,290,14" alt="q" shape="rect"/> ><AREA href="#p" coords="260,0,273,14" alt="p" shape="rect"/> ><AREA href="#o" coords="242,0,255,14" alt="o" shape="rect"/> ><AREA href="#n" coords="225,0,238,14" alt="n" shape="rect"/> ><AREA href="#m" coords="208,0,221,14" alt="m" shape="rect"/> ><AREA href="#l" coords="190,0,203,14" alt="l" shape="rect"/> ><AREA href="#k" coords="171,0,184,14" alt="k" shape="rect"/> ><AREA href="#j" coords="156,0,169,14" alt="j" shape="rect"/> ><AREA href="#i" coords="138,0,151,14" alt="i" shape="rect"/> ><AREA href="#h" coords="121,0,134,14" alt="h" shape="rect"/> ><AREA href="#g" coords="104,0,117,14" alt="g" shape="rect"/> ><AREA href="#f" coords="86,0,99,14" alt="f" shape="rect"/> ><AREA href="#e" coords="69,0,82,14" alt="e" shape="rect"/> ><AREA href="#d" coords="52,0,65,14" alt="d" shape="rect"/> ><AREA href="#c" coords="34,0,47,14" alt="c" shape="rect"/> ><AREA href="#b" coords="17,0,30,14" alt="b" shape="rect"/> ><AREA href="#a" coords="0,0,13,14" alt="a" shape="rect"/> ></MAP> ><IMG height="15" width="447" border="0" usemap="#atoz_map" alt="" src="http://svn.gnome.org/svn/orca/trunk/test/html/letters.gif"/> ></TD> ></TR> ></TBODY> ></TABLE> ><P>Here is some text.</P> ></BODY></HTML>
Comment on attachment 106046 [details] our "backwards" imagemap test (from bbc radio4) I give up. *sigh*
There has got to be a way to view our html test files *as html* via the svn web interface.... Rich helped me find the answer to the question Will had asked on the subject (thanks Rich!!), but http://svn.gnome.org/svn/orca/trunk/test/html/backwards.html isn't quite right (displays it as text). Anyhoo.... While I sit in #accessibility at irc.mozilla.org.... Thanks Will, that's what I thought -- and tried. But I'm still not getting it (hence the above attachment snafus and sitting in #accessibility). Given a regular ol' table cell with some text and a couple of links: * The cell implements accessible Hypertext (ht) * ht.getNLinks() returns 2 * ht.getLink(0) returns an accessible hyperlink associated with the first of the two links (hl1) * ht.getLink(1) returns an accessible hyperlink associated with the second of the two links (hl2) * hl1.getURI(0) gives you the URI associated with the first link * hl2.getURI(0) gives you the URI associated with the second link What could be simpler? Given these imagemaps (be it radio4 or safeway) you have a table cell which contains an image which contains children of ROLE_LINK (one child per region in the map): * The cell implements accessible Hypertext (ht) * ht.getNLinks() returns 1 * ht.getLink(0) returns an accessible hyperlink (hl1) * hl1.getURI(0) gives you an empty string. The image implements accessible Hyperlink but not accessible Hypertext. In the spirit of being thorough, I queried the image's accessible Hyperlink interface and tried getURI(0). Another empty string. I'm really sorry to be this dense, but I need another hint. :-(
Removing Will from the summary. Alexander is in #accessibility and thinks this might be a bug rather than density on my part and asked me to file it. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=419786 If it is indeed a bug, we're blocked until the fix. If it isn't a bug, I'm blocked until I'm enlightened by Alexander. :-)
Update: Alexander (bless his heart) has just posted an initial patch for the bug I filed. That has got to be the shortest FF bug fix turn around time I've seen. It still needs reviewing, etc. I'll build FF and take a look tomorrow.
Just tried the patch. I see URIs!!! :-) Alexander and the FF a11y team rock! Leaving this bug as blocked for now because the patch was approved for 1.9, but post 3.0b4 freeze. We'll also have to add some additional handling to Gecko.py to grab the appropriate URI and parse it into something which will be meaningful to the user.
(In reply to comment #12) > Just tried the patch. I see URIs!!! :-) Alexander and the FF a11y team rock! > > Leaving this bug as blocked for now because the patch was approved for 1.9, but > post 3.0b4 freeze. We'll also have to add some additional handling to Gecko.py > to grab the appropriate URI and parse it into something which will be > meaningful to the user. Cool! OK - given that GNOME 2.22 freezes Sunday... Can you work up a patch for this bug that will work regardless of whether the FF version used is fixed or not? That is, the patch will give us all the wonderful info with the fixed version of FF, but won't break anything in Orca when used with the unfixed version of FF?
Sure thing. I've got a killer migraine atm so it probably won't be tonight. But I'll look at it some time tomorrow.
I think I'll send them that letter, its all well for us who use Orca ;) which is fixed on an hourly basis, but what about those poor people using windows screenreaders. Surely they wish to serve all their customers, not just the sighted once. Lets see how long the round trip time on this one is.
Alexander committed his fix to the FF trunk this evening. Changing the summary to reflect that we are no longer blocked.
We're re-blocked: https://bugzilla.mozilla.org/show_bug.cgi?id=424264 When I originally tested the patch Alexander created, we were getting different URIs. Code freeze kept it from getting checked in for a while. Yadda, yadda, yadda. Now everything has the same URI. :-( It's not clear to me what went wrong when. But I suppose that's neither here nor there. To make matters worse, this (or a related bug introduced into the FF trunk around 5 March) has broken line navigation for imagemaps (a la the bbc radio 4 page). I need to do a bit more debugging on the latter case. But Orca's fine with beta 4 and is not fine now. :-( I may open a separate bug on the line nav issue. But in the meantime I'm re-blocking us and revising the summary to reflect the broader issue.
w.r.t. the latter problem (line -- really all caret -- navigation being broken in the vicinity of imagemaps): Now that the FF guys have implemented the Hyperlink interface for imagemap links, getCharacterOffsetInParent() needs to check the parent for text. I've opened bug 523759 for that and should have a patch soon (pending the regression testing). w.r.t. the "still blocked"/safeway problem: Evan attached a patch to the FF bug. Looks like it's good. But I figured at this point it wouldn't hurt to toss our regression tests at his patch. :-)
https://bugzilla.mozilla.org/show_bug.cgi?id=424264 has been marked as FIXED. Moving this to "[to confirm]" and "---".
I can confirm the fix -- and that we need to do something on our end, and that we probably are currently doing a poor job on all URIs which don't have a "basename" (thing after the last slash). Proposed patch is pylinted and will be attached pending the results of the regression tests. Targeting for 2.24.
Created attachment 118395 [details] [review] revision 1 Passes the regression tests. Yea! Mike please test. Will please review/provide sanity check. :-) Thanks!
(In reply to comment #21) > Created an attachment (id=118395) [edit] > revision 1 > > Passes the regression tests. Yea! Woo hoo! > Mike please test. Will please review/provide sanity check. :-) Thanks! Looks fine to me, though it would be great to have an example URI in the comments so we have an idea of what we're facing. Thanks much for your work!
Created attachment 118482 [details] [review] added a new regression test and requested comments.
I'm noticing no problems with this patch.
Thanks Mike! Patch committed. Closing as FIXED.