Unable to select text with screen reader

[JasonXJ]

Details

• OS version: ChromeOS (but this is probably not limit to ChromeOS)
• xterm.js version: ToT

The .xterm-accessibility-tree element (and everything else within .xterm) has the css variable user-select set to none, so ChromeVox (and probably the screenreader on other platforms) is only able to select the row element but not the text inside it. The user is also not able to copy the text because of this.

I think the solution to this is:

1. override user-select for .xterm-accessibility-tree so that the text is selectable. We will also use css to hide the browser selection highlight.
2. Monitor the selectionchange event for the element, and sync the selection to the terminal (e.g. via term.select())

What do you think about this?

[Tyriar]

We may just be able to remove the user-select CSS rules when screen reader mode is on. The main thing we need to make sure still works is mouse selection and links and since pointer-events:none is on the accessibility tree it'll probably be fine.

Monitor the selectionchange event for the element, and sync the selection to the terminal (e.g. via term.select())

Is this needed? You would be using a screen reader to select the DOM element so you don't need the "native" xterm.js selection do you?

[JasonXJ]

Hi Tyriar, the a11y tree element is only supposed to interact with the screen reader. It is not supposed to be seen by the user (we currently hide it by setting css color to transparent). I beleve we don't want to change this when we allow user-select on the tree, because otherwise the user will see a selected text overlay on top of the canvas:

This is why I propose also hiding the selection with css, but sync the "native" xterm.js selection so that the canvas can be painted correctly. Does this make sense?

[Tyriar]

That sounds reasonable, provided it doesn't impact the experience in non-screenReaderMode

[JasonXJ]

I don't think anyone is working on this. I am planning to work on this in the coming days.