1846594 - Link announcement on the FirefoxView-Next includes the full URL address

Status: RESOLVED WONTFIX

(Firefox :: Firefox View, defect)

Description

[Anna Yeddi [:ayeddi]]

Attachment: Verbose_announcement_of_the_truncated_link_by_NVDA.png

set browser.tabs.firefox-view-next to true and ensure a screen reader (NVDA on Win, VO on Mac, Orca on Linux) is running

STR:

1. Navigate to any link within any list of links and listen to the full announcement

Expected:

1. URL that appears on-screen should be announced as such (truncated)

Actual:

1. While the URL appears to be truncated on-screen, it is announced fully by a screen reader which is verbose and unnecessary.

It looks like this is coming from a title attribute that includes the full URL and is appearing on-screen on hover as a tooltip (as expected), thus the a11y-severity is lowered to s4, but the announcement is still too verbose and is very difficult to follow, especially it would increase a cognitive load for screen reader users with cognitive and learning disabilities.

Comment 1

[Mike Kaply [:mkaply]]

Looking through Firefox, this appears to be how it works anywhere a URL is truncated via CSS. (I tried the history window and items on the bookmarks toolbar).

It's not related to the title tag.

So if this were to be fixed, it would need to be a larger Firefox fix.

I found this (very old) web page that talked about this - https://butterpep.com/line-clamp-overflow-ellipsis.html

And I did some quick tests with Chrome and it has the same problem.

Comment 2

[Anna Yeddi [:ayeddi]]

(In reply to Mike Kaply [:mkaply] from comment #1)

Looking through Firefox, this appears to be how it works anywhere a URL is truncated via CSS. (I tried the history window and items on the bookmarks toolbar).

It's not related to the title tag.

So if this were to be fixed, it would need to be a larger Firefox fix.

I found this (very old) web page that talked about this - https://butterpep.com/line-clamp-overflow-ellipsis.html

And I did some quick tests with Chrome and it has the same problem.

Thank you for the investigation, Mike!

Since it's not a custom behavior provided by the author (us), but is a default behavior provided by the user agent (again us, but wider us), we could close this bug, unless Jamie :jteh thinks this could/should be resolved on the platform level.

Comment 3

[James Teh [:Jamie]]

This is tricky. I think the reason accessibility API exposure doesn't truncate text according to text-overflow is that text-overflow is often specific to visual presentation. For example, in a list of items where the space is too small to fit the items, the text might get truncated, but really it ideally wouldn't be if there were more space. A sighted user might work around this by maximising the window, zooming, etc. In other words, we don't want to truncate the text semantically.

In the case of these URLs, it could be argued that this isn't so much a question of space, but rather that we don't want to burden the user with a very long URL. That is, perhaps we semantically want this URL to be truncated; it's not just an artefact of visual presentation.

I'd be curious to know what the "intent" was here. Is this purely visual due to space or did we want to limit the cognitive load for the user? If the latter, I'd argue the URL should be truncated in the markup, not using CSS. If the former, then I believe the current exposure is correct and this is a wontfix.

Comment 4

[Mike Kaply [:mkaply]]

It's purely visual.