Improve accessibility of Pulsar in general

[Eragonfr]

Have you checked for existing feature requests?

• Completed

Summary

The main text field for editing is not accessible for users that rely on accessibility tools.
It's impossible to use Pulsar with a screen reader. It seems that the rest of the editor is accessible but the main text field.

What benefits does this feature provide?

Users that need accessibility tools like a screen reader could use pulsar as a text editor.

Any alternatives?

No alternative option.
The text editor should use a textbox not only for the text input but for rendering it too.
That way a screen reader and accessibility tools would be able to read and help the user to edit text in the editor.

Other examples:

VSCode is accessible, maybe look into how they did it?

PS: I did a feature request but maybe it's more of a bug if it's unintended.

[savetheclocktower]

This is an absolutely legitimate feature request, but you can probably tell that it’d be a large undertaking. That’s not me saying no; it’s just setting expectations. I think we can make some improvements, but it won’t be like RTL text support where a small amount of effort can vastly improve the status quo.

Constraints

• We cannot simply “use a textbox […] for rendering” without losing nearly all of the functionality of the current editor. If it were that easy to render styled content into a textarea or something like it, the Atom folks would’ve done it from the get-go. I think some WYSIWYG editors try to mess with contentEditable, but that is its own separate nightmare, and not necessarily even an a11y improvement. From what I can tell, not even VS Code tries to make its main editing interface accessible; they just mirror it with a hidden textarea, as described below.

• Community packages are free to care or not care about a11y, and I imagine many don’t. Anything that places its own UI would have to pay at least a little attention to a11y; there’s not a whole lot that we could provide that would Just Work and relieve the community package author from that burden. (One exception is editor decorations; I elaborate on that below.)

• I’m putting the github package into its own bullet point because it’s a fraught subject. It’s a great built-in package with lots of care paid to keyboard support and focus management, but I don’t expect that it’s very a11y-friendly. This is the area of Pulsar that we have the least control over because of how complex the github package is and how much it relies on its own technology stack (ancient React) that is unlike any other built-in package. We’ve touched that package just a handful of times in the last few years, all of them in largely superficial ways. (I’ve worked on a ground-up rewrite of the github package off-and-on for over a year, but that’d just be the start; we wouldn’t get a11y for free just because we rewrote it in SolidJS.)

• We are a team of volunteers and we never have enough time for anything. For the situation to improve, one of those volunteers would need to make a11y their personal mission and give it a lot of attention. A comment on the Atom issue tracker mentions that VS Code “took at least a year and an entire team to become accessible,” and that’s with the resources of Microsoft behind them. Even if all we did was copy their approach entirely, I imagine it would take us that long.

  But the best way to speed this up would be to train new contributors. We’ve already got a small group of outside contributors who have each picked one specific area of the app to obsess over; I can think of two contributors who mainly care about ppm, and one who made it their job to improve the testing situation. If such a volunteer existed who was willing to focus on a11y, I would be happy to spend time getting them up to speed and ensuring their contributions got reviewed promptly.

Areas of improvement

Even before we compare ourselves to VS Code, I can think of some places where a11y support could be improved:

• Better a11y for keyboard navigation. I bet we don’t put proper aria- attributes everywhere we could (or perhaps anywhere at all) to indicate active states, disabled states, et cetera. We have a lot of custom UI controls in the app and I doubt they're using modern best practices for a11y. (This would be a fine place for an outside contributor to get started.)
• Better management of focus, and better reporting of where focus is and how it can be moved.
• There is no particular care paid to overlay decorations (that I’m aware of). There’s a custom atom-overlay element involved, so we almost certainly have enough control to improve how overlay content (like linter/hover tooltips) are presented to users of screen readers. ARIA has tools to make it easier to represent “floating” content on a web page, and we should use them.

VS Code

How does VS Code do it?

• Claude says VS Code’s got a special mode for screen readers. It enters this mode automatically when it detects a screen reader is being used, but the mode can also be opted into explicitly via configuration.

• For the editor itself (Monaco): screen-reader mode mirrors the content shown on screen into a hidden textarea so that screen readers can interact with it more easily.

  • Interestingly, that textarea-based strategy divides up buffer content into discrete pages. It’s apparently not a great idea to try to put all of the buffer contents into a textarea, so VS Code breaks it up into chunks and renders only the active chunk.

    TextEditor does something roughly similar: it “virtualizes” editor content such that we’re always basically rendering only the lines of code near the cursor, extending only as far as we need to based on the size of the viewport. But the textarea doesn’t have a constantly moving window like this; instead, it changes textarea content only when the cursor crosses from one page boundary to another.

• VS Code lets the user break up the process of selecting text into several discrete steps. The user can set the “anchor” of a selection with one command, then complete the selection later with a second command after they’ve moved the cursor somewhere else.

• VS Code lets you cycle through (e.g.) linting errors via keyboard shortcut.

• In screen-reader mode, the screen reader keeps track of cursor movement and announces to the user when a line has certain kinds of markers — lint messages, folds, breakpoints. Each such announcement can be configured independently.

• Diffs, in particular, are given an entirely different presentation that is easier for a screen reader to describe.

Specific ideas we can steal borrow from VS Code

In contrast to the section below, these are ideas that make much more sense as part of Pulsar core than as part of a community package:

• We can pretty easily replicate the discrete commands for setting selection boundaries.
• We should improve the way the editor announces overlay content (such as linter messages) — but it might be a challenge to genericize it. (Someone could also write a different UI presentation for linter — one different from linter-ui-default — explicitly designed for screen readers.)

Specific ideas community packages can steal borrow from VS Code

These are things we could do directly, but for which our approach probably wouldn't differ much from the approach of a hypothetical community package:

• Ideally, screen readers would be able to use the same UI presentation as other users — i.e., we’d be able to make the existing views accessible instead of making users with visual impairments use an alternate mode that may not get the same level of attention.

  On the other hand, alternate views are comparatively easy to implement — especially for community packages —without needing to know too much about the implementation details of Pulsar’s existing presentation. For instance: if someone cared about improving screen-reader support for git diffs, they could build a special view for it the way VS Code has. They’d have access to the same libraries and APIs that Pulsar itself uses to discover which files have been modified and exactly how their content differs from what’s in source control. They could then use that information to build whatever presentation they want.

• In theory, even editor support for screen readers could be done via community package — and if it can’t, then that’s what we should fix. This isn’t “make someone else do it” as much as it’s “make sure there are no blockers to doing this on Pulsar’s side.” The details would get complex, but the core idea (use a hidden textarea as an alternate interface to a TextBuffer) is architecturally rather simple, and the only thing that could complicate it is if there weren’t strong enough mechanisms to keep editor state in sync between the TextEditor and this parallel screen-reader interface. We should look for potholes like those and proactively fill them in before anyone tries to navigate this road.

Possible tickets

• Implement something like Monaco’s TextAreaEditContext — a parallel, hidden presentation of a slice of the editor content. Presumably this would be two-way bound: changes made via the typical interface would be reflected in the textarea, and changes made by a user to the textarea content via screen-reader would result in real-time updates to the main presentation strategy. Level of effort: HIGH.

  But let’s reduce the size of the initial work to improve the chances it might actually happen:

  • Ensure TextEditor is extensible enough for the described use case. Specifically: make sure a hypothetical ScreenReaderTextEditor could keep in sync with TextEditor’s cursor placement and selection state. It’s a design goal that practically anything the editor does could also be done by a community package; so if we were interested in doing this as part of the core editor, we’d want the same extension points to be present as a community package would. TextEditorComponent does try to conceal its implementation details and distinguish them from the public API, so it might be that we have to make more things public in order to enable this use case (having a hidden textarea that can stay in sync with editor updates). Level of effort: MEDIUM-LOW.

• Assess and improve the ARIA usage of atom-overlay — whether it uses live regions to announce its content. Assess how easily a screen-reader user can discover that such overlay content even exists; then attempt to add keyboard shortcuts that allow such users to cycle through all the visible overlays and have them read aloud in order. Level of effort: MEDIUM.

• Investigate and improve focus-trapping. Pulsar, like Atom before it, is very hands-on with focus management. That’s generally good for a11y. Claude thinks it could be a problem that the editor traps the Tab key and responds by inserting a tab character instead of moving focus to the next control. I don’t think this is necessarily a problem, but we can investigate it. (VS Code lets the user toggle between “normal” mode and “Tab moves focus” mode.) It’s also worth checking whether any of the new ways to manage focus on the web (since the mid-2010s when this stuff was last visited by the Atom team) could improve the experience of a keyboard user who also has a screen reader enabled. Level of effort: MEDIUM.

• Investigate adding commands for easier manipulation of selections. We should allow users to place the two boundaries of a selection in separate, discrete commands. This implies a new state to keep track of (no boundaries placed -> one boundary placed -> active selection) and isn’t necessarily easy to harmonize with multi-cursor support (but then multi-cursor support itself is probably a no-go for screen-reader users in the first place). But this sort of thing could even be implemented in a community package — thus making it easy to try several different approaches and pick the best one. Level of effort: MEDIUM-LOW.

• Find good high-contrast UI and syntax themes and either bundle them or link to them prominently. There is no built-in high-contrast mode, but there certainly could be if we decided to bundle one. Level of effort: MEDIUM to LOW (depending on whether we can adapt something that’s already out there or have to build our own).

Sources

• Monaco Editor Accessibility Guide
• VS Code Accessibility