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

Closed
nvaccessAuto opened this Issue Jan 1, 2010 · 12 comments

2 participants

@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.

@jcsteh jcsteh was assigned by nvaccessAuto Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2010.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment