Chrome/NVDA and images with short alt text announced as "unlabelled"

[patrickhlauke]

Steps to reproduce:

In Chrome, it appears that images with a short (3-letter) alt attribute are treated as unlabelled (and announced as such by NVDA), despite having a text alternative and accessible name? In Firefox, the problem does not appear ... so unclear if this is a bug with NVDA itself, or something that Chrome is not doing properly.

<img alt="Bob" src="...">

https://codepen.io/joshfarrant/pen/zxOZrWq

Actual behavior:

Chrome/NVDA announce the image as Unlabelled graphic Bob. To get missing image descriptions, open the context menu.

Expected behavior:

graphic Bob.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2024.4

Windows version:

Windows 11

Name and version of other software in use when reproducing the issue:

Chrome 131.0.6778.140 (Official Build) (64-bit)

[patrickhlauke]

(disregard the actual example test - of course those alt texts aren't good, but only there to test the bug. in real-world application, the bug was encountered when adding company logos with short acronym names, like "BMW" and "EY")

[Adriani90]

with chrome canary 133.0.6903.0 and NVDA last alpha I cannot reproduce.
I am closing as works for me.
Please comment with a link of a website that shows this behavior and we can reopen.
Maybe the website uses some sort of technique to hide the alt text for screen readers, but at least from the minimal test case it is not reproducible.

[patrickhlauke]

@Adriani90 just checked the example URL i already provided above (https://codepen.io/joshfarrant/pen/zxOZrWq) with the latest Canary 133.0.6903.0 (Official Build) canary (64-bit) ... and am still seeing the same buggy result.

[Adriani90]

Do you have UIA in Chromium set to “only necessary” in NVDA advanced settings? Von: Patrick H. Lauke ***@***.***> Gesendet: Mittwoch, 18. Dezember 2024 16:47 An: nvaccess/nvda ***@***.***> Cc: Adriani90 ***@***.***>; Mention ***@***.***> Betreff: Re: [nvaccess/nvda] Chrome/NVDA and images with short `alt` text announced as "unlabelled" (Issue #17549) @Adriani90 <https://github.com/Adriani90> just checked the example URL i already provided above (https://codepen.io/joshfarrant/pen/zxOZrWq) with the latest Canary 133.0.6903.0 (Official Build) canary (64-bit) ... and am still seeing the same buggy result. Screenshot.2024-12-18.154445.png (view on web) <https://github.com/user-attachments/assets/3a20679d-6933-4d4f-8543-60a2f7b2534f> — Reply to this email directly, view it on GitHub <#17549 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGVCP4PQUWUO4E3CAIJJ7ZL2GGKHBAVCNFSM6AAAAABT2ZDUICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGY3DENZZG4> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AGVCP4I2GEEVYN5NUJL4DK32GGKHBA5CNFSM6AAAAABT2ZDUICWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUYC5EM2.gif> Message ID: ***@***.*** ***@***.***> >

[patrickhlauke]

I'm running default settings in NVDA. Just checked, and yes, it's set to "Default (Only when necessary)"

[SaschaCowley]

@Adriani90 I can reproduce this with UIA in Chrome set to "only when necessary" or or "yes". I can also reproduce it with Narrator, and when inspecting the image with Accessibility Insights. This is a Chrome issue, not an NVDA issue. @aleventhal is this something Google is aware of?

[aleventhal]

Hi Sascha, the Microsoft Edge team manages the UIA implementation in Chromium.
However, they have UIA turned on by default in Edge, whereas Chrome uses the IA2->UIA bridge by default.
You can change Chrome's behavior with a command line argument: --enable-features=UiaProviderWin or --disable-features=UiaProviderWin.
If the behavior is broken when the bridge is used, but works when the native UIA support is enabled, then it's just a matter of time before it gets fixed.
If the behavior is broken with the native UIA support, then file a bug at crbug.com and we'll make sure it gets routed to the Edge team.

[patrickhlauke]

Confirming that Edge/NVDA behaves correctly, so this definitely smells like a Chrome bug.

[aleventhal]

Hi, can someone please file a Chromium bug and CC me?

[SaschaCowley]

@patrickhlauke could you please create a Chromium issue for this per #17549 (comment)

[patrickhlauke]

would be easier for somebody actually involved in the chromium project here to file it, but sure ... @aleventhal see https://issues.chromium.org/issues/389897606 (don't think i can CC anybody on that myself?)

[patrickhlauke]

also, unless i messed it up, tried running it with canary and --enable-features=UiaProviderWin ... and it still fails

[lucasradaelli]

Hey there, Lucas from the chromium project here. I am investigating this, but I can confirm this is a chrome related issue. I can repro this and will update you all once I find more.

[Adriani90]

@lucasradaelli any updates on this? Do you need more information from NVDA users?

[patrickhlauke]

The chromium issue was closed as fixed. While personally I don't think the solution was appropriate (lowering the character threshold to 3 before it pretends that an image is "unlabelled" when it clearly isn't) ... it fixes this specific case of alt="Bob" and similar three-letter alternatives. https://issues.chromium.org/issues/389897606

I'm going to close the issue here, as it's not an NVDA issue, but a "chromium knows best" issue.

[joshfarrant]

Best hope we never have to add alt text to logos for "HP" or "BP" then 🤦

[patrickhlauke]

Well, exactly. This simply adds a plaster over the fundamental problem of: if there IS an alt that's non-empty, don't lie and pretend that it's unlabelled. At a stretch, announce the alt text, then - in addition - offer a vibes-based/genAI interpretation... but hey, what do i know? /cc @lucasradaelli @aleventhal

[aleventhal]

Yes, we did something quick. Maybe somebody can suggest a rule that would be better but not too difficult. We're afraid of making things worse.

…

On Fri, Jun 6, 2025 at 9:44 AM Patrick H. Lauke ***@***.***> wrote: *patrickhlauke* left a comment (nvaccess/nvda#17549) <#17549 (comment)> Well, exactly. This simply adds a plaster over the fundamental problem of: if there IS an alt that's non-empty, don't lie and pretend that it's unlabelled. At a stretch, announce the alt text, then offer an additional vibes-based/genAI interpretation... but hey, what do i know? /cc @lucasradaelli <https://github.com/lucasradaelli> @aleventhal <https://github.com/aleventhal> — Reply to this email directly, view it on GitHub <#17549 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZXULW6L5SRVBZ7OXDL3CGLLRAVCNFSM6AAAAABT2ZDUICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBZGMYTQNBUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[patrickhlauke]

@aleventhal

Maybe somebody can suggest a rule that would be better but not too difficult

as said above: "don't lie and pretend that it's unlabelled [when the heuristics kick in because they think that the alt is too short] [...] announce the alt text, then - in addition - offer a vibes-based/genAI interpretation"

by all means, use heuristics, but don't willfully ignore what authors have actually done

[aleventhal]

@patrickhlauke Understood. Makes sense. We are human and may have taken a shortcut because somebody before us wrote the feature and we didn't understand the decision on this, and were afraid to change something. You touch it you own it! @lucasradaelli When you researched this, did you find any good reason to ignore short alt text? I can think of cases where an image might even even just a single letter.