Skip to content

Design Document: Screen Reader Mode

Daniel Imms edited this page Jun 24, 2019 · 2 revisions

Rendering and the DOM

  • The actual rendered rows on the screen could be in the DOM or in a canvas element for performance reasons.
  • There is an accessibility mode that does a bunch of extra stuff to enable screen reader support in VS Code
  • The accessibility tree is added to the DOM beside the actual rendered rows: Screen Shot 2019-06-24 at 12 18 17 PM
  • The accessibility tree is a virtual list using aria-posinset and aria-setsize
  • The accessibility tree is rendered in an animation frame (typical maximum of 60 times per second)

Input and the live region

  • There is an assertive live region used that has characters sent to it from the process as they come.
  • Whether characters that are typed are announced using the live region gets a little complicated. When a key is pressed the character is added to a queue (and announced by the regular textarea announce mechanism), the keystroke is then sent to the process (which could be on another server), it's evaluated and the response is sent back, once xterm.js gets this it will pop the last value from the queue and if they match do nothing, if they do not it will clear the queue entirely. This is how we differentiate typed characters vs generated output.
  • Tab in a terminal technically doesn't print anything but just advances the cursor, we use a space when tab is used.
  • The live region will read a maximum of 20 rows when not cleared, it is cleared when the user types.

Navigating rows

  • Focus listeners are added to the top and bottom elements that will scroll the virtual list so a screen reader can navigate through the output. (navigation mode? I forgot what it's called)
  • There are also a list of scroll commands that can be used via the command palette