User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

This was discovered when this other regression was discovered:
[Bug 1801756] Using Firefox Nightly with GMail I can no longer read the web page with NVDA using the mouse

This is to report LI specific regressions with using NVDA and the mouse to read content

Go to LI on the web using Firefox Nightly and a valid LI account

Actual results:

When using Firefox nightly:

Using the selector at the top of the web page select my network with the mouse/left click
Manage my network is presented in the left column and invitations in the column to the right
Some of the invitations text is silent when using the mouse cursor to read the content
If the content is not at top of page the selectors at the top of the web page are not spoken

Using the selector at the top of the web page select messages
Messaging inbox/list is presented in the left column and the active conversation is presented to the right
With multiple messages presented the message edit box is presented at the bottom
The icons at the bottom of the edit box and the maximize in the upper right corner will sometimes be spoken with mouse over but sometimes they are silent
It is as if they become in focus after the send button has been spoken...
When text is added to the edit box and overflow the box a scroller is presented on the right
When that scroller is presented the icons can no longer be spoken

Using the selector at the top of the web page select notifications
Manage notifications is presented in the left column and notifications are presented to the right
Many notifications are not spoken with mouse over
Notifications from specific users seem to be accessible

Using the selector at the top of the web page select home
The middle column is where the feed is presented
Below some feed entries there are controls to interact with the entry
The like control presents a bar of icons when the mouse cursor is over the like
The like presented icons are not spoken with mouse over

Expected results:

When using stable Firefox:

When my network is selected
All content of all invitations is accessible using the mouse to read the content
The selectors at the top of the web page are spoken even if the content is not at top of page

When messages is selected
The icons at the bottom of the edit box and the maximize in the upper right corner will always be spoken with mouse over
Even when there is the scroller on the right

When notifications is selected
All notifications are spoken with mouse over

When home is selected
The like presented icons are spoken with mouse over

Setting this to P2 since it is something we want to address in the next couple of releases before CTW rides the train.

:nlapre did you have a chance to verify these?

We looked into this a little. There seem to be several cases where there are icons with text beside them. If you mouse over the icon in Firefox Nightly, NVDA doesn't report anything, but if you mouse over the text, it is read correctly. In Firefox stable, mousing over the icon also reports the text.

Although this intuitively seems like ideal behaviour in Firefox stable, it's actually due to a bug in Firefox stable which is fixed in Nightly. NVDA mouse tracking is designed to read text, not controls. It asks for the character at the position of the mouse. Firefox stable incorrectly reports the first character, when in reality, there is no character there (because it's an icon). The same behaviour can be observed in other browsers too. Perhaps NVDA should report the control if there is no character directly under the mouse, but it doesn't at this stage.

Distilled test case:
data:text/html,<button><div style="display: flex;"><div style="width: 100px; background-color: red;" role="none"></div>test
If you mouse over the red area, Firefox stable + NVDA reports "test", but Firefox nightly does not. If you mouse over the text, both stable and nightly report "test". Chromium browsers are consistent with Firefox nightly.

Thank you for the report! I've been investigating these issues, trying to reproduce them.

In addition what Jamie describes above, I've managed to reproduce a number of the other problems described here. This is just me confirming what I can in a first pass; I want to narrow these things down to individual and clear examples that don't require a LinkedIn account, but I've got to wade through a lot of weird CSS to get there, so here's my initial report. I'm going to number these to make it easier to discuss:

1

If the content is not at top of page the selectors at the top of the web page are not spoken

I see the same; if the scroll bar is at the very top (if you haven't scrolled down the page at all), then moving the mouse over the text of the main menu navigation buttons will read that text out on Nightly. However, if you scroll down the page a bit, NVDA won't read out the text, even if you mouse over it directly. I think there are z-order issues here; the main menu navigation buttons appear to "float" or stick to the top of the content area no matter how far you scroll the feed. I notice that, rather than read the text of the menu buttons, NVDA instead reads whatever content those buttons are covering. There are a few issues here in this same vein.

2

The icons at the bottom of the edit box and the maximize in the upper right corner will sometimes be spoken with mouse over but sometimes they are silent

I see the same; this one is complicated, and probably multiple issues. I'll try to explain them piece-by-piece:

a

NVDA seems to only read out the text associated with these buttons when I mouse over the spots in which the pushbutton's bounds intersect with the bounds of its text leaf child. The text leaf child contains the info that the user would presumably like to know about what the button does. On Stable, NVDA will read out the relevant text no matter where you mouse over the button.

b

One crucial thing to note is that the message edit buttons ("the icons") appear to "cover" the scrollable area containing the text of the direct message. I think this makes a difference, and is probably related to z-order issues. Importantly, you can only get that behavior I described in the previous point to occur consistently when you scroll the message text area to the bottom. Otherwise, we seem to hit some z-ordering issues and NVDA won't read some button's text, no matter where you put the mouse. On Stable, NVDA will read out the relevant text no matter the message's scroll state.

c

A thing not reported here, but that I noticed while debugging, is that, on Nightly, after opening and closing the Developer Tools, the buttons never report text. I can't fix it without refreshing the page.

3

When text is added to the edit box and overflow the box a scroller is presented on the right
When that scroller is presented the icons can no longer be spoken

I can reproduce a weird version of this. The steps are not great considering they're probably very screen-size-dependent. I'm looking for a better description, but this is what I have:

1. Open a message, scroll to the bottom of message text. Have the Nightly window not taking up the entirety of the screen. The buttons work, with the above caveats.
2. Type a bunch of text on a single line into the message response text area. It can be anything, it seems. This creates a scrollbar. The buttons still work, in my testing.
3. Maximize the Nightly window.
4. Now, the buttons don't work, even when grabbing cursor focus out of the edit box.

Some notes on these weird repro steps:

• You can also do this in the other order (window maximized to not)
• Sometimes NVDA doesn't tell you that you're hovering over buttons (once you've reproduced the issue).
• The breakage here is very similar to what happens when you open and close the Developer Tools (as described above).
• I can't reproduce any of this in Stable.

4

Many notifications are not spoken with mouse over
Notifications from specific users seem to be accessible

Confirmed; even when mousing directly over text where it appears, it's not read out. Some of the notifications are read out, as reported, but it's very unclear to me whether there's any pattern there. Initial thoughts are that it has to do with the combination of (1) where the text is in relation to the link that contains it and (2) what sits "on top" of it. As with all of these, I need to dig more.

5

The like presented icons are not spoken with mouse over

I can reproduce this, too. This is a really difficult one to test, since this toolbar comes up only on hover, and I have yet to find a way to get it to stick around long enough to even check it out in the inspector. Regardless, what seems to be happening pretty clearly is that this is another z-ordering issue; NVDA reads out the elements that are behind the floating "like options" toolbar. So, instead of reading out something like "like celebrate support funny love insightful" it'll read out the element behind it, such as "Nathan LaPre and 20 others" (describing the existing reactions).

Nathan, whenever something isn't read (e.g. NVDA reads nothing or reads something beneath it), are you able to confirm whether the bounds of the thing that isn't being read are correct? This would involve enabling NVDA menu -> Preferences -> Settings -> Vision -> Highlight navigator object, finding the item in question with NVDA's browse mode cursor and confirming whether NVDA's highlight is in the position you would expect.

A thing not reported here, but that I noticed while debugging, is that, on Nightly, after opening and closing the Developer Tools, the buttons never report text. I can't fix it without refreshing the page.

This and other things suggest that we're sometimes not updating the viewport cache correctly. It might be interesting to do some logging or debugging or whatever where we send/receive the viewport cache update to see whether we hit that when, for example, closing Dev Tools. Similarly, it might be useful to confirm that we send/receive scroll position/viewport cache updates when scrolling causes hit testing problems.

(In reply to Nathan LaPré from comment #4)

1

If the content is not at top of page the selectors at the top of the web page are not spoken

I see the same; if the scroll bar is at the very top (if you haven't scrolled down the page at all), then moving the mouse over the text of the main menu navigation buttons will read that text out on Nightly. However, if you scroll down the page a bit, NVDA won't read out the text, even if you mouse over it directly. I think there are z-order issues here; the main menu navigation buttons appear to "float" or stick to the top of the content area no matter how far you scroll the feed. I notice that, rather than read the text of the menu buttons, NVDA instead reads whatever content those buttons are covering.

I suspect this is less about z-order issues and more that we're calculating the bounds incorrectly for these fixed/sticky elements. I filed bug 1809836 for this. I didn't mark it as blocking this because I'm not certain this is the problem - I don't have a LinkedIn account - but I have a very strong suspicion.

Additional clarification to help with reproduction:

3

When text is added to the edit box and overflow the box a scroller is presented on the right
When that scroller is presented the icons can no longer be spoken

While using LI in Firefox Nightly with NVDA
I usually use a tab and the browser is maximized
Not full screen as that eliminates other information at the top of the browser/window...

When I start to compose a message in LI it is often a reply to another
However, that may not be required...
I think the key here is the scroll bar on the right
It is not presented until you enter more lines than fit in the edit box
You simply need to enter lines until the scroll bar is presented

I neglected to include these observations in my initial report... :-(
These are probably the things I do the most.

There are several sections of an LI profile that are not spoken with mouse over
This only happens wit nightly and not stable
In other words, if yu bring up an LI profile for review
Reviewing it with the mouse cursor cannot access all content

When using the my network tab in LI
If you search for someone/something using the search box
The search results are presented as a list
This search results list is similar to notifications
Works in stable but not in nightly
So it is like this:

4

Many notifications are not spoken with mouse over
Notifications from specific users seem to be accessible

Thank you for your patience and for reproducing and clarifying these issues!

(In reply to James Teh [:Jamie] from comment #5)

Nathan, whenever something isn't read (e.g. NVDA reads nothing or reads something beneath it), are you able to confirm whether the bounds of the thing that isn't being read are correct? This would involve enabling NVDA menu -> Preferences -> Settings -> Vision -> Highlight navigator object, finding the item in question with NVDA's browse mode cursor and confirming whether NVDA's highlight is in the position you would expect.

Sure! In the case where the user hovers over a button such as the message response buttons (attach a file, open emoji keyboard, other send options, maximize compose field, etc.) and nothing is read at all, such as when the user opens then closes the Developer Tools, NVDA shows what are clearly stale bounds. In particular, imagine the buttons are at the bottom of the content area and Nightly window. When the Developer Tools come up, taking up the entirety of the bottom third of the content area, those buttons move up to adjust, and NVDA agrees. When I close the Developer Tools, those buttons snap back to the bottom of the window visually, but their bounds remain as if the Developer Tools were still open. I should note that the same inaccuracies of bounds can be triggered by resizing the window (as occurs in (3) in my description above, re: the direct message scrollbar). And, upon further investigation, the window resizing is the only thing necessary to break things. The scroll bar bit seems irrelevant to that; maybe another issue I have yet to narrow down.

In the case of the persistent LinkedIn navigation menu that has fixed position despite the scroll state of the feed, the bounds appear similarly incorrect on scroll. It appears the bounds are "stuck" to the top of the page, even though visually the toolbar remains above the feed as I scroll down. If I scroll just slightly (maybe half of the button height), I can see the bounds have similarly been offset halfway up above the button.

For LinkedIn notifications, a situation where NVDA reads "article link" but not the actual text leaf descendant of the link, the bounds appear correct.

In all the stale bounds cases, are you able to confirm whether there is an ancestor element with CSS position: fixed or position: sticky? I'm guessing there is. If so, we'll deal with that part over in bug 1809836.

For LinkedIn notifications, a situation where NVDA reads "article link" but not the actual text leaf descendant of the link, the bounds appear correct.

It'd be interesting to know whether the text leaf has correct bounds. To do that, you'll need to find the link with the browse mode cursor, then use NVDA's move to first object inside command (desktop NVDA+numpad2, laptop NVDA+shift+downArrow). That should get the review cursor/navigator to the text leaf, which should then get highlighted.

For LinkedIn notifications, a situation where NVDA reads "article link" but not the actual text leaf descendant of the link, the bounds appear correct.

The fix for bug 1808828 might also help here.

(In reply to James Teh [:Jamie] from comment #11)

In all the stale bounds cases, are you able to confirm whether there is an ancestor element with CSS position: fixed or position: sticky? I'm guessing there is. If so, we'll deal with that part over in bug 1809836.

The global navigation bar (id 'global-nav' as of time of writing this) is a header element with property position: fixed; the buttons of the main menu bar are descendants of that element.

The buttons on the direct message panel, on the other hand, don't appear to have position: fixed or position: sticky in their ancestors. The button text has position: absolute and the buttons are position: relative in a footer, in a position: static form.

For LinkedIn notifications, a situation where NVDA reads "article link" but not the actual text leaf descendant of the link, the bounds appear correct.

It'd be interesting to know whether the text leaf has correct bounds. To do that, you'll need to find the link with the browse mode cursor, then use NVDA's move to first object inside command (desktop NVDA+numpad2, laptop NVDA+shift+downArrow). That should get the review cursor/navigator to the text leaf, which should then get highlighted.

So, I'm a bit confused about this one. The bounds that NVDA reports for the text leaf are identical in Nightly and in Stable, but only Stable actually reads the text out when I move the mouse cursor over it. For what it's worth, the bounds look incorrect to me in both, at least for the notifications that don't get read out in Nightly. They do not tightly bound the text; rather, the bounds are offset such that the top of the bounding rectangle sits at the bottom of where the text appears visually. For notifications that are read out properly in Nightly, the bounding box on the text looks correct. I'm trying to narrow down the differences between the HTML, since they're rather different between notifications.

Here are two example working notifications:

<!-- first -->
<button aria-label="Send message to Jane Doe" type="button">
  <span>
    Wish <strong>Jane Doe</strong> a happy birthday. (Jan 12)
  </span>
</button>

<!-- second -->
<a href="clipped link" tabindex="0">
  <span>
    <strong>1 person</strong> viewed your profile: Stay anonymous and see who's viewed your profile with Premium
  </span>
</a>

and here's an example broken notification:

<a href="clipped link" tabindex="0">
  <span>
    <span aria-hidden="true"><strong>John Doe</strong> has 8 new connections. View all John’s connections.</span>
    <span class="visually-hidden">John Doe has 8 new connections. View all John’s connections.</span>
  </span>
</a>

The visually-hidden class provides the following CSS:

display: block !important;
border: 0 !important;
clip: rect(0 0 0 0) !important;
height: 1px !important;
margin: -1px !important;
overflow: hidden !important;
padding: 0 !important;
position: absolute !important;
white-space: nowrap !important;
width: 1px !important;

(In reply to Nathan LaPré from comment #13)

The buttons on the direct message panel, on the other hand, don't appear to have position: fixed or position: sticky in their ancestors. The button text has position: absolute and the buttons are position: relative in a footer, in a position: static form.

Hmm. I wonder if bug 1774705 is relevant here. I've just put a patch up there, so it might be worth a shot.

So, I'm a bit confused about this one. The bounds that NVDA reports for the text leaf are identical in Nightly and in Stable, but only Stable actually reads the text out when I move the mouse cursor over it. For what it's worth, the bounds look incorrect to me in both, at least for the notifications that don't get read out in Nightly. They do not tightly bound the text; rather, the bounds are offset such that the top of the bounding rectangle sits at the bottom of where the text appears visually.
...

<a href="clipped link" tabindex="0">
  <span>
    <span aria-hidden="true"><strong>John Doe</strong> has 8 new connections. View all John’s connections.</span>
    <span class="visually-hidden">John Doe has 8 new connections. View all John’s connections.</span>
  </span>
</a>

That is deeply frustrating. For some reason, they've hidden the visually shown text with aria-hidden so it doesn't appear in the a11y tree, but then they've provided exactly the same text for a11y purposes but hidden visually. The incorrect highlight you're seeing is the "visually hidden" bounding box, which clips the text so it's invisible but is positioned below the visually shown text for some reason. We can't hit test the text on screen because it's been deliberately removed from the a11y tree; as far as a11y is concerned, it doesn't exist. IMO, this is very poor authoring.

I don't understand why this works in Firefox stable. Maybe it's due to that fuzziness that Firefox stable seems to exhibit with regard to matching text. I'm guessing this won't work in Chromium, though, and strictly speaking, it probably shouldn't.

(In reply to 4RJames from comment #9)

I neglected to include these observations in my initial report... :-(
These are probably the things I do the most.

No worries! Thank you for reporting!

There are several sections of an LI profile that are not spoken with mouse over
This only happens wit nightly and not stable
In other words, if yu bring up an LI profile for review
Reviewing it with the mouse cursor cannot access all content

I can very much confirm this. It looks like a ton of the the content on the LinkedIn profile page follow that same deeply frustrating pattern of hiding the visually shown text with aria-hidden, then providing the same text for a11y, hidden visually. And when I say "a ton," I mean "virtually everything you might care about on the page." It looks like this pattern appears quite a lot on LinkedIn, but especially on the Profile page.

When using the my network tab in LI
If you search for someone/something using the search box
The search results are presented as a list
This search results list is similar to notifications
Works in stable but not in nightly

I think this is the same as above (aria-hidden on one element, and then the same information for the accessibility tree as a sibling element). It's harder to verify since this dropdown goes away and makes inspection tricky, but I'd be surprised if it isn't the same issue.

(In reply to James Teh [:Jamie] from comment #14)

(In reply to Nathan LaPré from comment #13)

The buttons on the direct message panel, on the other hand, don't appear to have position: fixed or position: sticky in their ancestors. The button text has position: absolute and the buttons are position: relative in a footer, in a position: static form.

Hmm. I wonder if bug 1774705 is relevant here. I've just put a patch up there, so it might be worth a shot.

I've tried your patch out locally. I didn't observe a change in behavior. The bounds of the buttons are still stale after opening and closing the developer tools panel, or after resizing the window such that the buttons move position.

I've spent some time today getting myself to debug firefox remotely from another machine, in order to test the issues that have to do with hover or dropdown menus that otherwise disappear when shifting focus to the dev tools.

In regard to this bit from above:

The like presented icons are not spoken with mouse over

The reactions menu that pops up when hovering the mouse cursor over the Like button has six buttons in a row. The bounds of each of these buttons are incorrect in Nightly. NVDA shows the bounds as offset down and to the right of the visual location of the buttons. The buttons are position: relative within a position: absolute span that describes the menu. Side note: as far as I can tell, people who are using a keyboard only to navigate the feed can only "Like" posts - they can't access any of the other reactions.

(In reply to Nathan LaPré from comment #15)

(In reply to 4RJames from comment #9)

When using the my network tab in LI
If you search for someone/something using the search box
The search results are presented as a list
This search results list is similar to notifications
Works in stable but not in nightly

I think this is the same as above (aria-hidden on one element, and then the same information for the accessibility tree as a sibling element). It's harder to verify since this dropdown goes away and makes inspection tricky, but I'd be surprised if it isn't the same issue.

I debugged this remotely, too, but it looks like this is fixed in Nightly now. Turns out it's not the same aria-hidden issue that I thought it was. If you mouse over the text itself it won't be read out. It shares the difference with Stable that mousing over the svg to the left of each suggested result does not read the text.

This might be better but I don't think it is fixed in nightly...

(In reply to Nathan LaPré from comment #15)

(In reply to 4RJames from comment #9)

    When using the my network tab in LI
    If you search for someone/something using the search box
    The search results are presented as a list
    This search results list is similar to notifications
    Works in stable but not in nightly

I think this is the same as above (aria-hidden on one element, and then the same information for the accessibility tree as a sibling element). It's harder to verify since this dropdown goes away and makes inspection tricky, but I'd be surprised if it isn't the same issue.

I debugged this remotely, too, but it looks like this is fixed in Nightly now. Turns out it's not the same aria-hidden issue that I thought it was. If you mouse over the text itself it won't be read out. It shares the difference with Stable that mousing over the svg to the left of each suggested result does not read the text.

Some information is still not spoken and some information is spoken when the mouse is below the actual content

I seem to be having similar issues in search results from Google searches...
Some results are completely accessible while others are not.
I don't know why they are different...

I seem to be having similar issues in search results from Google searches...
Some results are completely accessible while others are not.
I don't know why they are different...

I see this, too. I've logged it here: Bug 1811972. Thanks for all of this testing, it's helping so much!

The like presented icons are not spoken with mouse over

The reactions menu that pops up when hovering the mouse cursor over the Like button has six buttons in a row. The bounds of each of these buttons are incorrect in Nightly. NVDA shows the bounds as offset down and to the right of the visual location of the buttons. The buttons are position: relative within a position: absolute span that describes the menu.

Narrowed this down after much fiddling. Looks like this issue should be resolved when this bug is fixed: Bug 1806356.

Thanks for all your hard work!

Using the firefox nightly from today's update

Responding to a post on LI to provide feedback
I noticed additional points...

Before responding the presentation is different than after
The presentation of icon/label for: like, comment, repost, send

Before responding:
The label is below the icon
The like is not spoken using mouse over
There is no spoken feedback for the bar of icons that pop up from the like
after responding:
The label is to the right of the icon
The like is not spoken using mouse over
There is no spoken feedback for the bar of icons that pop up from the like

(In reply to 4RJames from comment #21)

Before responding the presentation is different than after

I think this should now be fixed, along with other issues with the bar of icons that pop up when you mouse over the "Like" button. This was a couple issues wrapped into one that have all been fixed.

I think this leaves us with two remaining issues here, though it's debatable how much Firefox is responsible for them:

1. LinkedIn duplicates information across two elements, visually exposing one but hiding it from the accessibility tree, then visually hiding the other but exposing it to the accessibility tree. See Jamie's Comment #14 above. This contributes to issues such as Notifications not being read out.
2. The matter of NVDA mouse tracking reading text, not controls. See Jamie's Comment #3 above. This causes issues such as "My Network" controls not being read out when mousing over an icon, despite this happening in Stable. This is also the culprit behind NVDA not reading out button text, such as in the Messaging view, and of NVDA not reading out the search suggestions if you mouse over the icon presented to the left of each search suggestion.

For what it's worth, Nightly matches Chrome/Edge's behavior on both of these points. It seems possible that we could restore whatever fudging we were doing with CtW off to address the second point, but whether we should is another question. I'm not sure how we can address LinkedIn's authoring choices from the first point.

(In reply to Nathan LaPré from comment #22)

It seems possible that we could restore whatever fudging we were doing with CtW off to address the second point, but whether we should is another question. I'm not sure how we can address LinkedIn's authoring choices from the first point.

I filed bug 1809082 to consider reimplementing this buggy behaviour. It should work around both problems if we decide to go ahead.

I wanted to follow up on this:

I think this should now be fixed, along with other issues with the bar of icons that pop up when you mouse over the "Like" button. This was a couple issues wrapped into one that have all been fixed.

With mouse over, the like button is spoken as add a comment...
The icons that pop up on the bar seem to be working

The buttons to the right of the like button that is spoken as add a comment are not spoken at all.
I think there are three of these the right most being send...

It is still not possible to review a LI profile using the mouse over method
For example, each entry of work experience usually cannot be read except the icon/business
Even when I copy paste these from LI to a GMail compose they are not accessible

(In reply to 4RJames from comment #24)

The buttons to the right of the like button that is spoken as add a comment are not spoken at all.
I think there are three of these the right most being send...

I think this primarily due to the second issue I outlined in Comment #22 above. It looks like this should be fixed by Jamie's work in Bug 1816601, but I will double-check to confirm that it addresses it.

It is still not possible to review a LI profile using the mouse over method
For example, each entry of work experience usually cannot be read except the icon/business
Even when I copy paste these from LI to a GMail compose they are not accessible

These are frustrating examples of the first issue I outlined in Comment #22 above. LinkedIn is choosing to present the information twice, once solely visually (with aria-hidden="true") and once solely for accessibility, causing the bounds for the visual presentation to not match the accessible bounds. This problem exists in Chrome and Edge, too, as a result. When you copy the information from the profile page into the GMail compose box, the problem comes along for the ride.

Thanks for all your hard work!
These things work well in Firefox stable.

This seems to be working correctly now:
The buttons to the right of the like button that is spoken as add a comment are not spoken at all.
I think there are three of these the right most being send...

However, the like button is not spoken with mouse over...
Although, the icons on the bar are spoken

(In reply to 4RJames from comment #27)

This seems to be working correctly now:
The buttons to the right of the like button that is spoken as add a comment are not spoken at all.

Great! Yeah, this behavior looks correct to me now, or at least at parity with Stable.

However, the like button is not spoken with mouse over...
Although, the icons on the bar are spoken

I observe this, too! It looks to me like this problem exists in Stable, too. Can you confirm that? This might warrant a separate issue, since it seems to be present with Cache the World on and off.

I believe all the issues here related to the caching implementation (what is used in Nightly) have been addressed. The issue with the like button is not addressed yet, but as per comment 28, that seems to be a problem without the cache (in stable) as well. Let's g et a separate bug filed for that to investigate after the caching work is released.

I'm going to close this, but please feel free to comment here or open a new bug for any further problems. Thanks so much for your invaluable help.

You're the best!
I was reviewing some LI profiles the other day and had to double check that I was really using Firefox Nightly and not stable! :-)
Thanks for all the updates!

With the latest Firefox Nightly I'm once again finding that the LI message edit box is no longer working correctly after scrolling the text of the message being composed...

This seems to be happening in multiple web applications again, including Google Bard.

As described previously, this is when using the mouse cursor to read the content.
Which is compounded by the loss of speech when using the arrow keys to navigate the same...
Which forces me to move focus out and back to recover...

Thanks for the heads-up! Could you specify what you're seeing in Google Bard? I've tried to repeat these failures there by putting in tons of text and scrolling, but haven't had much luck. I might be able to see the problem with more specific steps, if you get a chance.

Separately, could you elaborate a bit on how you're experiencing a loss of speech when using arrow keys to navigate scrolled text? I haven't been able to reproduce this, but I suspect I'm not taking the right steps.

I did notice an issue with the LinkedIn direct messaging view. Assume I've put a bunch of text into the direct message response edit box such that there's a vertical scroll bar. When the response text is not scrolled, there are hit testing issues with the buttons below the edit box (particularly "Attaach an image" and "Attach a file"). I think this is due to Bug 1825411.

Otherwise, I'm having trouble reproducing issues with the edit box. Hit testing seems to work for me on latest Nightly on the contents of the edit box. I'd love to check again with more specific steps, if possible.

I'm sorry I was not more clear...

About the arrow keys
I wish I could get this down to a repeatable sequence
I see this frequently when editing in many applications
When it happens the arrow keys no longer result in NVDA speaking the content
However, when you move focus out of the edit box and then return to the edit box they work correctly again
For example
I receive a message in LI and use the edit box below to start composing a reply
While composing I use the arrow keys to review what I have written
sometimes the arrow keys stop speaking the content
If I then use the mouse cursor and click on the message text I received above the edit box and then click back in the edit box where I'm composing the arrow keys will work again...

I recently updated to:
114.0a1 (2023-04-12) (64-bit)

I wanted to see if the problem was repeatable in LI message reply edit box
I started by clicking in the edit box below my previous reply
I started to type text on lines and hit enter and repeated this until the box filled and started scrolling
I was unable to repeat the problem with the mouse cursor reading the wrong lines of text in the edit box
The mouse cursor also read the buttons below the edit box correctly

However, the arrow keys would not read the text I was editing in the edit box!
Then I noticed something different...
I scrolled the edit box so the first line of text was showing
Now the mouse cursor is no longer reading the correct line of text
This is sort of the opposite of the original problem report
That is now the text at the top of the content is not read correctly using the mouse cursor
Before it was the text at the bottom

This is crazy but I think I just discovered what is making the arrow keys stop speaking!
When the arrow keys are working correctly
If I scroll the content they stop working correctly
I did that a couple times
When I went back to that tab I couldn't reproduce it

I'm sorry this was so long

I went back to Bard to check things on this version of Firefox Nightly
114.0a1 (2023-04-12) (64-bit)

Here's what I found
I did a number of prompts until the history is flowing up above the space in the window
I can read everything that is showing using the mouse cursor

Now if I scroll up to review the history it still works fine using the mouse cursor

However, when I scroll back down to expose the most recent response
The mouse cursor is no longer reading the correct line of text

Thank you so much for the details! I can reproduce the mouse cursor issue reliably, but am not having luck reproducing the arrow key issue.

Regarding the mouse cursor problem: It looks as if we're failing to update the cached scroll position of the scrollable region. The bounds that NVDA is reporting for the edit box do not update when scrolled, even if I throw focus elsewhere then bring it back. Usually, I'd expect to see the bounds shift up and down as I scroll (even if some of the text is hidden by other elements). Seems this is a problem both when hit testing and when not hit testing. The same type of thing is showing up in Google Bard's response history: the positions of the content don't update on scroll.

All of these issues resolve themselves when I adjust the bounds of the Firefox window just a bit (triggering a reflow?). I wonder if we need to push scroll position updates more aggressively? It's unclear to me when it gets stuck; it's not always acting as if it's stuck at scroll position (0,0) - sometimes it's stuck in some other scrolled position. Any thoughts on this Jamie?

This does seem pretty bad - it might be worth spending some time trying to get us down to a minimum reproducer. AKA, stripping out a bunch of LinkedIn cruft (increasingly familiar to me).

This sounds suspiciously like bug 1809379. Is this a textarea element or a contenteditable?

I did add tests with that fix, so I don't think that fix could have broken, but maybe there's a similar problem happening here.

This contenteditable test case seems to work for me, so it's not specific to contenteditable itself:

data:text/html,<div contenteditable style="height: 20px; overflow: scroll; width: 2ch;">a b c d e f g h

That said, reading this again, I'm a bit confused. Nathan, you said, "The bounds that NVDA is reporting for the edit box do not update when scrolled." Do you mean when the content of the edit box is scrolled or when something else is scrolled that causes the edit box to move? I wouldn't expect the bounds of the edit box to change when its content is scrolled, so I'm guessing you mean the edit box is inside a scrollable container?

Sorry for the bad explanation - hopefully this following test case makes it more clear what I mean:

data:text/html,<div style="height:100px; overflow:scroll;"><div id="text"></div></div><button onClick="let html=''; for (let i = 1; i <= 20; ++i) { html += i; html += '<br>'; } document.getElementById('text').innerHTML = html;">Add Text</button>

Click the "Add Text" button, then note the bounds of the "text" id. Scroll the scrollable region to the bottom. Note that the bounds of the text id have not changed accordingly. At this point, hit testing the scrolled text will report results as if it's unscrolled.

The contenteditable bit doesn't matter, but it does seem important that the text be entered after page load.

Thank you; that's super helpful.

1. What's happening here is that the overflow div isn't getting an Accessible, so we can't cache scroll data on it.
2. Normally, when something is scrollable, it gets an Accessible because its scrollability makes it focusable and focusable things always get Accessibles.
3. In this case, the div wasn't scrollable initially, so we didn't create an Accessible for it.
4. Often, when something becomes scrollable, it causes reflow, in which case we would re-evaluate the div and create an Accessible for it.
5. In this case, I guess it doesn't get reflowed, perhaps because the size of the div itself doesn't change. Thus, we don't create an Accessible for it.

We can fix this by always creating an Accessible for elements which have overflow: scroll or overflow: auto. To do that, we should be able to extend Morgan's creation patch over in bug 1825611.

We should file a new bug for this.

Today after upgrading to:
115.0a1 (2023-05-11) (64-bit)
I'm again having trouble using LI with the mouse and NVDA...
I'm under pressure and moved to Firefox stable without any problems
I will follow up with more details when I have more time.

I was unable to easily review individual LI profiles
As well as lists of connected users
When using the mouse and NVDA

Thanks for this report :)
I think I have a test case, I'll file a new bug

I have also had to retreat to stable to review notifications using the mouse
Could no longer do it using:
115.0a1 (2023-05-16) (64-bit)

(In reply to 4RJames from comment #42)

I have also had to retreat to stable to review notifications using the mouse
Could no longer do it using:
115.0a1 (2023-05-16) (64-bit)

Can you describe the issue in more detail? What notifications do you mean?
What are you expecting and what's happening instead?

Sorry I was not more clear
This was previously reported, fixed, and stopped working again.

Sign into LI and select the notifications button at the top of the web page
I almost always use a maximized window for this tab...

Position the mouse over the list of notifications to review the content with NVDA
Some of the icons for businesses are spoken and some are not...
The content/text to the right of the icons is no longer spoken

This is possible using stable and an earlier version of nightly

Thank you!

I think I understand the issue better now -- cc :Jamie

Prior to my overflow:hidden patch, this markup:

<a href="link">
  <span>
    <span aria-hidden="true">I am some text hidden from a11y</span>
    <span style="overflow:hidden; height: 1px; width: 1px; position: absolute; clip: rect(0 0 0 0);">I am some a11y-rendered text</span>
  </span>
</a>

generated the following tree:

> link
> > text leaf: I am some a11y-rendered text

Where the link has the bounds as defined by the text node "I am some text hidden from a11y". The text leaf "I am some a11y-rendered text" has bounds equivalent to the bounds of that text, if it were visible on the page and not overflow:hidden; (ie. if it had overflow:auto;). This text is below and outside of the link's bounds.

If you hittest the link, you'd get "I am some a11y-rendered text" despite the bounds for that text node not actually being within the link

Now, a few intermediate spans get forced into the tree, such that the structure looks like:

> link (bounds visually equivalent to "I am some text hidden from a11y")
> > generic (bounds same as link)
> > > generic (0 x 0 bounds where the following text leaf's origin is, below the link's bounds)
> > > > text leaf: I am some a11y-rendered text (bounds equiv to this text node as it'd be rendered visually)

If you hittest the link you get... nothing :)

I mocked up the same tree to test on fx release, to see if this was an issue with those intermediate 0 nodes, or an issue with the tree structure -- seems to be more of a tree structure problem. The issue reproduces on fx release with the following:

data:text/html,<a href="google.com"><div id="a"><div aria-hidden="true">hello world text</div><div style="overflow:hidden; height:1px; width: 1px; position:absolute; clip: rect(0 0 0 0);">hello world text but for a11y</div></div></a>

Hittesting the link returns null.

:Jamie any idea why adding an intermediate div would make it such that the link no longer hittests? It seems odd to me that the link gets its bounds from a node that is hidden from the a11y tree (and not, say, the text leaf that does get rendered to a11y).

Interested in your thoughts -- this is hard to explain, though, let me know if I can clarify any of the odd bounds behaviour.

I should add, I think our behaviour now is technically more correct given the text node that a11y sees isn't within the link. But this seems to be common enough UX that we need to figure out a way to get it working...
It still isn't clear to me what about our hittesting algorithm would cause this to fail, since, as I understand it, we should still return the link itself for any point hittest within it. Debugging, debugging...

(In reply to Morgan Reschenberg [:morgan] from comment #45)

data:text/html,<a href="google.com"><div id="a"><div aria-hidden="true">hello world text</div><div style="overflow:hidden; height:1px; width: 1px; position:absolute; clip: rect(0 0 0 0);">hello world text but for a11y</div></div></a>

Hittesting the link returns null.

If I hit test on the RootAccessible at the centre of the link, I don't get null. I get the div. But...

How are you hit testing the link? What origin Accessible and coordinates are you using? NVDA is going to hit test on the RootAccessible using the coordinates at the mouse cursor; i.e. somewhere within the link.

It seems odd to me that the link gets its bounds from a node that is hidden from the a11y tree (and not, say, the text leaf that does get rendered to a11y).

The link gets its bounds from layout and I think that's perfectly reasonable. What's unreasonable is the way LinkedIn have authored this. They're neglecting to acknowledge that not all screen reader users are purely keyboard users and some actually use the mouse. But such is life on the wild web.

Nevertheless, what I think is happening here is that hit testing is returning an ancestor of the text leaf, but not the parent. The problem with that is that when NVDA calls OffsetAtPoint, it will call it on the ancestor, which of course doesn't contain the text (since it's not a direct child), leaving the user with a grand sum total of nothing. The reason it doesn't return the parent is that the parent's bounds are not inside the link. The fact that it worked before is a happy accident: because that intermediate just happened not to be in the tree.

A possible (albeit horrible) path forward is that we could perhaps exclude those forced generics from hit testing results. We can't do this for all generics, only the ones we force into the tree. I'd rather not have another cache property for those, so perhaps we can figure out a proxy for that info: width and height less than a certain size + overflow/transform? Or maybe we'll just have to cache that fact after all.

A possible (albeit horrible) path forward is that we could perhaps exclude those forced generics from hit testing results.

Durp, that's not going to help. That'll return the link instead of its child generic, but the link still won't contain the text. To make that work, we'd have to return the link's grandchild generic (the parent of the text leaf), which is the one with the 0x0 bounds.

I'm not quite sure what to do here...

Discussed further with Jamie -- NVDA and VO have diverging hittesting experiences. We can get VO to parity with Safari if we ignore generics when hittesting, but we can't get this to work on NVDA unless we fudge the bounds of the text node such that it looks to be inside of the link.
It's possible we can do this with a complex conditional, but this boils down to poor authoring and isn't strictly a browser bug.
Will test, but I think NVDA on Chrome and Edge will behave the same as FF nightly

(In reply to Morgan Reschenberg [:morgan] from comment #49)

Will test, but I think NVDA on Chrome and Edge will behave the same as FF nightly

I tested Chrome and Edge on Windows with NVDA, and they behave the same as FF Nightly. That is to say, while hit testing, NVDA doesn't report the content authored with this visually hidden two-step in those browsers either.

I don't know where things stand at this point...

I wanted to update that LI profiles are much less accessible using nightly with the mouse and NVDA:
115.0a1 (2023-06-01) (64-bit)

I still must use stable for LI.

(In reply to 4RJames from comment #51)

I don't know where things stand at this point...

I wanted to update that LI profiles are much less accessible using nightly with the mouse and NVDA:
115.0a1 (2023-06-01) (64-bit)

I still must use stable for LI.

What URL do you see under "about:buildconfig" for "Built from"?
When you say "much less accessible" do you mean compared to stable or compared to previous nightly? Are you seeing new issues?
We just landed a patch at bug 1832686 that should improve accessibility for users using NVDA + mouse

I'm sorry I was not more clear...

When I started this bug there were several issues
Many things were addressed
However, things have regressed since
Which is why I said I don't know where things stand...

Firefox stable still works well using the mouse and NVDA
Firefox nightly has gone backwards

Should I assume all the changes are in and I should reevaluate and report my findings here in the comments?

Should I do the same for the GMail regresssions in nightly?

Yes, the changes should've landed in Nightly. Please let us know what issues you're seeing so we can take a closer look

When using nightly version:
115.0a1 (2023-06-03) (64-bit)

There are several sections of an LI profile that are not spoken with mouse over
This only happens with nightly and not stable
In other words, if yu bring up an LI profile for review
Reviewing it with the mouse cursor cannot access all content

• There are icon/buttons on the right below the background image on some profiles
• Below the number of followers/connections and above the message button are the mutual connections
• Next to the message button is a more button and when activated the popup menu is read but not accessible to the mouse but works using the arrow keys
• Most of the remaining content of the profile is not accessible using the mouse

When using the home tab in LI:
The content in the middle of the page are posts from other users
The business/user icon is accessible using the mouse but the information to the right is not

When using the my network tab in LI
If you search for someone/something using the search box
Then you select show all results
The search results are presented as a list
The icon and name to the right are not accessible using the mouse
The other content is accessible

When using the notification tab in LI:
Some notifications are not accessible using the mouse
Notifications from other users seem to be accessible...

I have been adding comments for GMail on this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1801756

(In reply to 4RJames from comment #55)

When using nightly version:
115.0a1 (2023-06-03) (64-bit)

There are several sections of an LI profile that are not spoken with mouse over
This only happens with nightly and not stable

Thank you for taking the time to write this report, this is super helpful :)
:nathan can you test the following with NVDA? I'll post my results testing with VO below, but I can't reproduce everything and I'm wondering if there's some platform specific bugs here

In other words, if yu bring up an LI profile for review
Reviewing it with the mouse cursor cannot access all content

• There are icon/buttons on the right below the background image on some profiles

I think this is in reference to the enable/disable notifications button below the profile header -- this is readable with mouse + VO

• Below the number of followers/connections and above the message button are the mutual connections
• Next to the message button is a more button and when activated the popup menu is read but not accessible to the mouse but works using the arrow keys

These are both readable with VO also

• Most of the remaining content of the profile is not accessible using the mouse

I can read most of the profile content using VO + mouse, however the bounding box for the VO cursor is still drawn where the invisible text is, and not around the node we're actually mousing over (it does still read the moused-over node though -- see, for ex. the company name on an item in the "Experience" list.

Some items cannot be reached (ie. position title in an item on the experience list)

When using the home tab in LI:
The content in the middle of the page are posts from other users
The business/user icon is accessible using the mouse but the information to the right is not

This is reproducably broken with VO -- I can get VO to speak the poster's icon/profile pic, but I can't read their name, position, or company. I can access the "follow" button if one exists, and I can see the degree of connection next to their name. I can read post content, reactions, amount of comments, etc.

When using the my network tab in LI
If you search for someone/something using the search box
Then you select show all results
The search results are presented as a list
The icon and name to the right are not accessible using the mouse

The list of search results for people in my network is accessible with VO and mouse -- I can read all the info

The other content is accessible

When using the notification tab in LI:
Some notifications are not accessible using the mouse
Notifications from other users seem to be accessible...

This is reproducable. I can read notifications that come from actual users and their activity (ie. connections making posts or starting new jobs) but I when I try to read LinkedIn supplied notifications (their icons say "Get Hired" and "Get Ahead" etc. and the notification content is usually something like "Using AI to write a resume may backfire. Here's why."), VO correctly reads the moused over node, but the bounding box is drawn incorrectly (over the invisible text). I can't get VO to voice "image" when mousing over the icon in the notification, but the posting time and three dot menu are readable

Ahhh I think the issue has to do with the fact that linkedin occasionally puts a single whitespace character at the same level as their hidden text node container, making our algorithm of "descend generics until a single text leaf child is reached" non-functional... hmmm.. I'll think about how to patch this. Spinning off another bug :)

(In reply to Morgan Reschenberg [:morgan] from comment #56)

:nathan can you test the following with NVDA? I'll post my results testing with VO below, but I can't reproduce everything and I'm wondering if there's some platform specific bugs here

In other words, if yu bring up an LI profile for review
Reviewing it with the mouse cursor cannot access all content

• There are icon/buttons on the right below the background image on some profiles

I think this is in reference to the enable/disable notifications button below the profile header -- this is readable with mouse + VO

NVDA doesn't read these buttons out, unfortunately. I need to file a bug about this with a reduced test case. EDIT: added to 1837030 here. Frustratingly, the upsell link to buy premium is only presented visually hidden.

• Below the number of followers/connections and above the message button are the mutual connections
• Next to the message button is a more button and when activated the popup menu is read but not accessible to the mouse but works using the arrow keys

These are both readable with VO also

NVDA doesn't read these out, either. Regarding the mutual connection text: this seems to be a problem with having multiple text leaf children. We have:

• LINK
  • LIST
  • GENERIC ""
    • GENERIC ""
      • TEXT LEAF "Person X"
      • TEXT LEAF ","
      • TEXT LEAF " "
      • TEXT LEAF "Person Y"
      • TEXT LEAF ","
      • TEXT LEAF ", and 1 other mutual connection"
  • TEXT LEAF " "

This feels distinct from Bug 1837024.

• Most of the remaining content of the profile is not accessible using the mouse

I can read most of the profile content using VO + mouse, however the bounding box for the VO cursor is still drawn where the invisible text is, and not around the node we're actually mousing over (it does still read the moused-over node though -- see, for ex. the company name on an item in the "Experience" list.

Some items cannot be reached (ie. position title in an item on the experience list)

Most of the things on rest of the profile seem to be the same problem as Bug 1837024, based on what I'm seeing in dev tools. Others are Bug 1837030, and some are likely both. I think the times where VO reads something that NVDA doesn't are mostly down to Bug 1837030.

When using the home tab in LI:
The content in the middle of the page are posts from other users
The business/user icon is accessible using the mouse but the information to the right is not

This is reproducably broken with VO -- I can get VO to speak the poster's icon/profile pic, but I can't read their name, position, or company. I can access the "follow" button if one exists, and I can see the degree of connection next to their name. I can read post content, reactions, amount of comments, etc.

Same with NVDA on most counts here, except that NVDA does not read the "Follow" button to me, nor does it read the number of comments and reposts. These are aria-labeled buttons with aria-hidden children. It's unclear to me why NVDA doesn't read the label - maybe :Jamie would know?

When using the my network tab in LI
If you search for someone/something using the search box
Then you select show all results
The search results are presented as a list
The icon and name to the right are not accessible using the mouse

The list of search results for people in my network is accessible with VO and mouse -- I can read all the info

I can confirm that this content isn't accessible to NVDA, though I'd like to try again after the resolution to Bug 1837030.

When using the notification tab in LI:
Some notifications are not accessible using the mouse
Notifications from other users seem to be accessible...

This is reproducable. I can read notifications that come from actual users and their activity (ie. connections making posts or starting new jobs) but I when I try to read LinkedIn supplied notifications (their icons say "Get Hired" and "Get Ahead" etc. and the notification content is usually something like "Using AI to write a resume may backfire. Here's why."), VO correctly reads the moused over node, but the bounding box is drawn incorrectly (over the invisible text). I can't get VO to voice "image" when mousing over the icon in the notification, but the posting time and three dot menu are readable

I can reproduce this, too, with the same caveats that it's a bit worse on NVDA than on VO due to Bug 1837030. Otherwise, I think it generally has to do with the problem described in Bug 1837024.

Today while using Firefox Nightly:
116.0a1 (2023-06-12) (64-bit)

I was in the my network tab, selected from the top of the page
Using the mouse to read content with NVDA
Most content was accessible, however, I noticed something strange...
In the middle of the page there were invitations presented
Most of them were completely accessible.
One of them at the top of the list had a text message that was clipped and had the usual see more hyper link
Below this text was a reply button
When I would hover the mouse over the text message it would often not speak...
But sometimes if I moved the mouse over different parts of the text it would read it...
I could not find a way to make this predictable and it may have been further confused by a delay in responding.
It seems like it matters if you are moving up or down when you positino the mouse over this text message...

I then went to Firefox stable to see if in this case things were different
I was surprised that it seemed to do the same thing!

Perhaps this is an NVDA problem dealing with this hyper link

BTW
Using my previous case
If I click on the see more and expand the text message it works fine
When I click on the see less the problem comes back

It's worth noting that for several of the issues here, at this point, we're effectively hacking around authoring problems in LinkedIn. Several of these things don't work in other browsers at all, but we'd like to ensure users can access as much as possible despite the authoring errors, so we've persisted in trying to work around these. We've tried politely contacting LinkedIn to ask them to fix these problems on their side, but unfortunately, they have stopped responding, so we're stalled there. Ultimately, even if we can get this partially working, there are going to be some things that are either unreliable or don't work at all. Still, we'll do our best.

Thanks again for all your hard work!

I have used LI with NVDA and Firefox for many years and don't know what I would have done without it!
Fortunately, most things still work with stable...

If there is anything I can do with regards to contacting LI support let me know.

Oh my, what happened?

I've been away for some days...
Today I received an email with a link to view a message on LI
I opened the link in a new tab using Firefox Nightly
I cannot read any content on that LI page using NVDA with teh mouse over
I updated Firefox Nightly to this version:
117.0a1 (2023-07-06) (64-bit)
Again, nothing was accessible...

I tried to do this with Firefox stable
I used the same link and got the same results

I discovered everything on the web page was like ghosted
I hit the escape key a couple times and it seemed to become unghosted
Then content seemed to become accessible as expected

I went back to nightly
I refreshed the page and then hit the escape key a couple times
Then content seemed to become accessible as expected

I don't know what caused this and I heard something spoken like toast so I suspect something was being presented...

I hope this helps

This is still happening

When I receive an email message indicating that I have received a new LI message there is a link to take you to the message in LI
When this link is activated a new tab opens in Firefox and a message dialog is presented over the ghosted LI main page
at this point nothing is accessible when using the mouse with NVDA

While I can use the mouse to select/copy the content presented in the message dialog it is not read by NVDA

Having left that tab, when I return I can click in the edit box and get NVDA to read the prompt and any text that is entered

Moving the mouse over other content in that message dialog area sometimes results in things being read that are not under the mouse cursor

In order to work around this inaccessible message dialog box I have to close it and navigate to the messages tab at the top of the LI page and then find the corresponding message

Not very productive :-(

(In reply to 4RJames from comment #64)

This is still happening

When I receive an email message indicating that I have received a new LI message there is a link to take you to the message in LI
When this link is activated a new tab opens in Firefox and a message dialog is presented over the ghosted LI main page
at this point nothing is accessible when using the mouse with NVDA

While I can use the mouse to select/copy the content presented in the message dialog it is not read by NVDA

Having left that tab, when I return I can click in the edit box and get NVDA to read the prompt and any text that is entered

Moving the mouse over other content in that message dialog area sometimes results in things being read that are not under the mouse cursor

In order to work around this inaccessible message dialog box I have to close it and navigate to the messages tab at the top of the LI page and then find the corresponding message

Not very productive :-(

Interesting....
I can only occasionally repro this with VO, but Nathan can reproduce this with NVDA consistently.
We're not sure what's going on here, but we're looking into it :)

Thank you for the report!