Issues with web content

Like my thread about text, I think a specific topic about web content issues with voiceover on the mac (all browsers and vo settings included, also electron apps) could be very helpful.
A random list would be:
1. Impossible to use voiceover and correct text in html textarea. This has been the case since my first macos version Ventura til now. VO can detect there is an error, but none of the usual way to access the corrector (and there is quite a lot of different ways) work. Lookup works though and is surprisingly useful! Almost as good as this French software Dic on windows. Moreover, the rotor for paragraph, sentences, and especially misspelled word elements don't work at all and VO revert back to the closest, for me it's either Navigation or text field.

2. Safari (or any other browser) does not respond. I'll leave other app such as system settings and pages out as I specifically want to talk about this bug in web content. It has fortunately gotten less worste since Sonoma 14.2, but an easy way to reproduce it is have a very very long thread in chatgpt and you can feel VO gradually becoming slow. Another parallel issue to this is when you use one of the find commands, headings, links... and VO says searching (appname), and is stuck in a frozen state for a very very long time or until we restart it. Even then cmd-f5 doesn't always work and sometimes I need to triple click touch id so the popup window for accessibility option is in the foreground and VO has to get in the new ui, where it becomes more or less responsive again. I brows a lot, and even now after 1.5 years this issue is still present (applevis users say it's about 5-6 years old), I just can't trust voiceover to actually work with me for whatever task I have to do. Generally speaking, when there is a lot of web content, or especially in PWAs and advanced javascript controls, voiceover hasn't really gotten as good as windows screen readers for the modern web apps and.

3. Focus issues, specifically preventing to do a cmd-enter on a heading with a link in it to open that webpage in a new tab. I have this often on applevis website and google search. For the latter I always set new search results to open in new tab so it's not really a problem there, but on applevis I often have to use my right arrow (quick nav off) so the keyboard cursor is positioned on the link, and then I can press cmd-enter. Interacting in the heading, then the text, ... can sometime work but it's not reliable.

4. In multi line textarea, voiceover command to navigate text with vo arrow keys can often make the cursor leave the text area and on a random place close to this, which makes the navigation by paragraphs for example using various VO commands uncertain (discussed on the text issues thread).
https://www.applevis.com/forum/macos-mac-apps/voiceover-text-handeling-navigation

5. On teams for example in chrome, you can't always use the line rotor to navigate line by line in a message in a chat, VO crashes and reloads. And of course selecting two lines is impossible as discussed in the other thread, because 1 line is 1 different element for VO.

6. Navigating by next/previous form control on reddit for example can often go to the first or last form control of the page.

7. You can infinitely interact even beyond the text on some page or elements of the page until the cursor randomly refocuses itself close to the original location but then you still have to go all the way up or use vo-shift-escape as otherwise VO will again restart and you are likely to be positioned in the Finder windows, or anywhere except in the browser.

8. The complex a webpage gets, the less likely you are to get text attributes with vo-t, you won't hear anything in any of the message in applevis forum for example, while NVDA and jaws don't have any problem on Windows. Depending on the context and especially for STEP student this can be detremental, for MLA/APA for example. In pdf, you just have nothing. Yet in both cases when there is an actual italic element chances are that with vo-cmd-i/shift-i you can find it, same thing for font change or bold for example, but you will never get the full picture while this information is often present in the very code of the web page.

Generally speaking, even when I really try to navigate like Apple think VO users on the mac should navigate on the web, I just feel that Voiceover is against me in every step of the process. A friend of mine who also has a mac put it very simply this way: macos and voiceover rendering of the web don't encourage you to brows it.
I know that web is handelled in a completely different way than windows screen readers, but the problem is that it's already difficult for webdev to find actual good articles about web accessibility, and when they do these are often made for windows screen readers first as they're the most popular one within the blind community, which create a horrible vicious circle for voiceover web accessibility on the mac and the blind users. Apple are known to don't change their mind even when they are prooven to be ineffective or straight wrong, and because it's related to accessibility, we get the worst of all this in return.

And updates tend to do the most random things and break them on a per page basis, but the real problem is voiceover developers don't seem to do enough compatibility and unit testing with what is the main ui/os for blind users to interact with the real system.