NVDA does not silence images embeded inside links even with alt="" present

[nvaccessAuto]

Reported by vtsaran on 2009-09-22 05:20
This behavior is confirmed in both Firefox and IE.

With the following code:

Check out the new Yahoo!

NVDA will read out as follows:

Link Check out the new Yahoo! graphic www.yahoo.com

It seems that NVDA should

1. Ignore the graphic altogether because of an empty alt attribute; and
2. Not read out the URL because the link text is present.

[nvaccessAuto]

Comment 1 by vtsaran on 2009-10-01 05:57
A live example of this behavior would be the Yahoo! Search results page at http://ysearch.com in the "search refiners" section. Here is an example link using the search term of "origami":
http://search.yahoo.com/search;_ylt=A0geu.ABRMRK0AUBUbKl87UF?p=origami&fr=sfp&fr2=&iscqry=
You will notice that under the section "Search refiners NVDA reads out a lot of graphics which are embeded or are simply beacon attributes.

[nvaccessAuto]

Comment 2 by vtsaran on 2009-11-13 04:16
Is there a hope for this to be fixed before the final release of NVDA? I think, it would be great to sort out ALT attributes issue considering that NVDA is used as a testing tool by many.

[nvaccessAuto]

Comment 3 by jteh on 2009-11-13 04:19
I'm afraid this won't make it into 2009.1. However, we should definitely try to get it into the next release, which hopefully won't be anywhere near as long in coming as this one. :)
Changes:
Milestone changed from None to 2009.2

[nvaccessAuto]

Comment 6 by jteh on 2010-01-20 22:00
Committed in r3468. Wow, that was quite tricky!
Changes:
State: closed

[nvaccessAuto]

Comment 7 by vtsaran on 2010-02-11 21:24
Has this really been fixed? I just wwent to Yahoo! Search results page and looked under the "search refiners" section. The extraneous information is still spoken on graphics.
Can you please elaborate on what exactly was fixed?

[nvaccessAuto]

Comment 8 by jteh on 2010-02-11 22:35
Damn it. :) NVDA was fixed so that it doesn't read the graphic URL if there is content inside the link other than the graphic. We still want to render it if there is no content because otherwise, it'd be impossible to activate links that have only a graphic with alt="" (bad authoring).

Unfortunately, it looks like this is exactly what Yahoo! Search does. There is no content inside the link other than the graphic. Unfortunately, the graphic is also inside a "paragraph" node, which means that our code for detecting this case doesn't pick it up (it looks for a graphic which is an immediate child of the link). I'm guessing the link is using aria-label or some such. We don't tend to rely on just the accName because this wouldn't allow us to use the URL for graphics which have no labels.

I have no idea how to fix this for Yahoo! Search.

[nvaccessAuto]

Comment 9 by jteh (in reply to comment 8) on 2010-02-11 23:21
Replying to jteh:

Unfortunately, it looks like this is exactly what Yahoo! Search does. There is no content inside the link other than the graphic.

Wrong. I appear to be braindead. There is text content; that is how the label of the link is being derived. I think the problem is the paragraph node containing the graphic. Our code queries whether the link has a name; it doesn't account for graphics being grandchildren of the link.

[nvaccessAuto]

Comment 10 by jteh on 2010-02-22 02:31
Btw, Vic, to clarify, the test case you provided in the ticket description has been fixed. As noted, Yahoo! does something a bit different (the graphic is a grandchild of the link instead of a child) which is not covered by this fix.

[nvaccessAuto]

Comment 11 by vtsaran on 2010-02-24 20:47
OK, let me see if we can solve this on our side. But you are right, as far as my original example goes, this has been fixed. Thanks!

[nvaccessAuto]

Comment 12 by jteh on 2010-02-24 21:17
Note that I'm working on a fix for NVDA. I already have it working for IE, but getting it working for Gecko is going to be a bit harder due to it being older code. I can't promise it'll be in 2010.1.

[nvaccessAuto]

Comment 13 by vtsaran on 2010-09-04 18:30
Jamie, do we need to reopen this bug or keep it closed?

[nvaccessAuto]

Comment 14 by jteh on 2010-09-05 22:18
The issue originally described by this ticket has been fixed and the fix is in a previous release. We should open another ticket for the remaining issue.