fix urls with screenreader

[jerch]

@Tyriar This small change fixes things for the url event listeners. Idk if it will break some functionality on screenreader side, thus it furthermore needs proper testing with a screenreader app being attached.

[Tyriar]

@meganrogge could you try this out? Previously pointer-events weren't going through beyond the a11y dom tree in order for the text outlines to work correctly by hovering with a mouse for low-vision users. I'm not sure this is still a problem?

[meganrogge]

Before the change vs after the change 👍🏼

Using VoiceOver with this setting, I was hoping that the link would get announced, but it doesn't. It did not before the change either.

vo.mov

[jerch]

... I was hoping that the link would get announced, but it doesn't. ...

I think this highly depends on what underlying data structure/event the screenreader will trigger its link announcement. This is prolly DOM link related, but while we visually mimick a DOM link here, the underlying data is still nowhere close to a DOM link firing its hover event. But it might be possible to fake that as well in the aria container. Maybe just attach a link provider listener, that places a DOM link and triggers a hover in the aria element will already do? (Have lit. no clue about aria events, so this is just a wild guess...)

[Tyriar]

@meganrogge it occurs to me now we probably shouldn't have ripped out the a11y tree considering we moved the accessible buffer feature into vscode's codebase #4503

[RahjIII]

Thanks for the fix. Verified in xterm 5.2.1.