Closed Bug 1508870 Opened 11 months ago Closed 11 months ago

NVDA doesn't guess label from URL for unlabelled image links

Categories

(Core :: Disability Access APIs, defect, P2)

All
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla65
Tracking Status
firefox65 --- verified

People

(Reporter: Jamie, Assigned: MarcoZ)

Details

Attachments

(1 file)

STR (with NVDA):
1. Open this URL:
data:text/html,<a href="https://mozilla.org"><img src="https://placeholder.com/20.png"></a>
2. Press down arrow to read the only line.
Expected: NVDA should say "link  graphic  20"
Actual: NVDA just says "link"

If you disable AccessibleHandler, this works as expected. This seems to go all the way back to Firefox 58!
Oops. That URL should be:
data:text/html,<a href="https://mozilla.org"><img src="https://via.placeholder.com/20.png"></a>
Same STR and results though.
Looking at the NVDA code, my guess is that we're not differentiating between null and the empty string for accName and are instead always returning the empty string even if Gecko actually returned null. We probably need to tweak CopyBSTR in AccessibleHandler.h so that it returns null if the source string is null.
When determining if an author provided an empty alt attribute versus no alt attribute at all, our image accessible name is either an empty string or a null string. Screen readers can then choose to guess the name from the source if the author did not explicitly provide an empty alt text and thus marked the image as decorative.

The accessible handler for the Windows remote processes did not account for this distinction, always returning what appeared to be an empty string.
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/af8241e64ecb
Make a distinction between an empty returned string versus a null pointer, r=Jamie
https://hg.mozilla.org/mozilla-central/rev/af8241e64ecb
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Flags: qe-verify+

Hello,
I have tried to reproduce this issue with the affected build, as well as the latest nightly and beta , but I could not trigger the
expected: "link graphic 20". Instead I get the "Link graphic mozilla.org" .

Flags: needinfo?(mzehe)

You need to make sure that the current build is cleanly uninstalled and no other builds are there in other registered directories that might have a newer AccessibleHandler than the one you're trying when reproducing with the affected build. I definitely confirmed that the issue was there before the bug fix and is now solved.

Flags: needinfo?(mzehe)

Hello Marco ,

I have re-tried this issue with a cleanly uninstalled Firefox . No other builds were in any other registered directories and made sure the following paths are completely clean :

%userprofile%\AppData\Roaming\Mozilla
%userprofile%\AppData\Local\Mozilla
%userprofile%\AppData\LocalLow\Mozilla

Was still unable to reproduce any other string except the one provided in Comment 6.

Flags: needinfo?(mzehe)

Jamie, do you hae any idea what might be going on here? I remember us explicitly verifying the fix for this issue...

Flags: needinfo?(mzehe) → needinfo?(jteh)

Sorry. My bad. The expected result is incorrect. It should be "link graphic mozilla.org" as described in comment 6. I verified this with the handler disabled and also by looking at the NVDA code. If the graphic is inside a link with a URL, the URL of the link is used to derive the text, not the URL of the image.

In case anyone wonders, note that you'll get "link graphic 20" with NVDA in Chrome because Chrome doesn't expose the URL of the link via IAccessible::accValue on the image.

Flags: needinfo?(jteh)

Thank you James for clarifying this issue.

In that case, if the expected string is the one provided in comment 6 (Link graphic mozilla.org) ,then this issue is confirmed as verified fixed on Win 10x64.

Currently, if performing the STR provided, the "Link graphic mozilla.org" string will be heard via NVDA tool.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.