@x0 Yes, I believe both of these are valid issues to create: 1. Collapse leaving containers announcements into shorter messages, such as "out of 2 lists, out of 3 articles, etc...". 2. When activating same page links, announce where the cursor moved to first, and then any other information, such as out of container messages.

@NikJov OK good! Would be helpful to see if those issues exist already, if not sounds useful to create. Actually, there's a potential thing. Is that what that one setting report formatting changes after the cursor does? It reports font and whatnot *after* the current line, instead of before? Why does it cause a lag? Would it be the same here? Worth investigating with someone who knows about that setting. Also this new setting should perhaps respond differently to arrowing vs other, larger forms of navigation. Maybe a combo box that's like, report container exits: always first. After content when navigating. Always after content.

@x0 @NikJov Those both look like really good and clear issues, thank you!

Good question! I rarely see JAWS issues raised here. However, when it comes to fixing issues, FreedomScientific is way faster. Yes - they may have more full-time employed devs or whatever, and JAWS has got its own issues. But the majority of my reported NVDA bugs, or the bugs others have reported which affect my workflow, cannot be found in JAWS at all.
@NikJov @x0

@jcsteh @NikJov Oh. Yeah that'd be screwy. I'd just use commas but then, oxfard comma? And that final and? Commas alone might have to be enough. How would that stack up? Makes sense.

@x0 Heh, I didn't mean to dig deep on this. My point is that it wouldn't be entirely grammatical on matter what you do, and I actually think that's fine. Screen reader output isn't inherently grammatical, despite what people try to suggest. And I think it would be far less efficient if it were fully grammatical. Imagine: "This is a button labelled OK which is currently pressed." Yuck.

@x0 @NikJov Kinda, but even now, the entire stack is processed and the string is assembled in one hit before it is sent ot the synthesiser, so I doubt that would be a perceivable performance hit. It would, however, involve a pretty significant rewrite of that code with additional parsing and heuristic logic, which is the bigger problem here.

@jcsteh @NikJov That might be more of an issue for quick navigation and that multimode setting I was talking about yeah. And gets slightly funky depending on exactly what bits in the architecture get involved to assemble such a message. If it generated something like closing events or tokens or whatever, you'd have to collect them all, sort them in some fashion, and then output that. IDK how that would be anymore sluggish than the current system, if a set is so nested it lags it would lag regardless because it's still jsut one string, no?