What Is the Mac Accessibility API and Why Does It Matter for Writing Tools?

The macOS Accessibility API (AXObserver, AXUIElement) is a framework that allows apps to observe and interact with the text fields and UI elements of other apps. Originally designed for screen readers and accessibility tools, it's also used by Charm to provide system-wide writing correction in apps that block the standard text input pipeline, including Slack, VS Code, and Discord.

Why do Electron apps block standard autocorrect?

To understand why the Accessibility API matters, you first need to understand how macOS handles text input and where that system breaks down.

macOS has a native text rendering system built around NSTextView, which is the framework all native Mac apps use to display editable text. NSTextView is deeply integrated with the rest of the operating system, including NSSpellChecker. When you type into a Notes document, Pages file, or Mail message, the text passes through NSTextView, and NSSpellChecker can inspect it, flag misspellings, and offer corrections.

Electron apps, including Slack, VS Code, Discord, and Notion, do not use NSTextView. They are built using Chromium, the same open-source browser engine underlying Google Chrome. Text fields in Electron apps are web content rendered inside a browser window. From macOS's perspective, they look the same as a text field on a website inside Safari - and NSSpellChecker does not connect to web content in the same way.

The result: 73% of popular productivity apps use Electron, making the standard NSSpellChecker pipeline unreachable for nearly three quarters of the apps most knowledge workers spend their time in. Built-in macOS autocorrect is simply absent in those apps, with no setting to turn it on and no workaround available at the app level.

How does the Accessibility API enable system-wide correction?

The macOS Accessibility API provides a different path to the same text. Instead of hooking into the text input pipeline, it observes the UI layer at the OS level, watching for changes to the values of UI elements across all running applications.

The two core components are AXObserver and AXUIElement.

AXUIElement is a reference to a specific UI element in another app - a text field, a button, a window. Using AXUIElement, an app can read the current value of a text field or write a new value to it, regardless of how that text field is implemented. A native NSTextView, a Chromium web renderer, and a custom text widget all expose an AXUIElement interface that looks the same to the observer.

AXObserver watches for notifications from those elements. When text changes in any text field, AXObserver fires an event. Charm registers an AXObserver on every text input field across all running apps, which means it receives a notification every time you type, regardless of which app you're in.

When Charm receives a text change notification, it reads the current text value via AXUIElement, runs the correction model locally, and if a correction is needed, writes the corrected text back via AXUIElement. The entire cycle takes under 50ms and happens entirely on-device, with no network activity.

This approach works identically in a native Notes window, a Slack message, a VS Code comment, and a Discord message. The rendering technology used by the host app is irrelevant because Charm operates at the OS-level UI layer rather than the text input pipeline layer.

What permission does the Accessibility API require?

Because the Accessibility API grants the ability to read and write UI elements in other apps, macOS requires explicit user approval before any app can use it. The permission is a single toggle in System Settings > Privacy and Security > Accessibility.

When you enable an app in this list, you're granting it the ability to observe and interact with UI elements across the system. This is intentionally visible and user-controlled: Apple chose to surface this as a named permission rather than a background capability, so users know which apps have been granted this level of access.

The permission is not unique to Charm. Many well-known and widely trusted productivity apps use the Accessibility API for their core functionality. Raycast uses it to display inline UI over other apps. Alfred uses it to interact with windows and text. 1Password uses it to detect form fields and offer autofill. BetterTouchTool uses it to read window state and trigger actions. All of these apps appear in the same Accessibility list and require the same toggle.

Is using the Accessibility API safe?

The Accessibility API is a legitimate, documented Apple framework. Using it is not inherently safe or unsafe - it depends entirely on what the app does with the access.

The concerns worth considering are: does the app transmit text it reads? Does it store text it reads? Does it use the access for anything beyond its stated purpose?

For Charm, all three questions have clear answers. Charm runs entirely on-device. No text is transmitted to any server. The app requires no account, no login, and no network connection for its core features. The Accessibility API access is used solely to detect text changes and write corrections. The optional OpenAI API integration for enhanced grammar is explicitly opt-in and disabled by default - it is the one case where text leaves your device, and it requires you to supply your own API key.

The broader point is that the permission system is working as intended. Apple surfaces Accessibility access as a visible, user-controlled toggle precisely because the capability is significant. The fact that Charm (and Raycast, Alfred, 1Password, and dozens of other trusted apps) requires this permission is not a warning sign - it's the permission system functioning correctly, giving you informed control over what each app can do.

Frequently asked questions

What is the macOS Accessibility API?

The macOS Accessibility API is a framework built around AXObserver and AXUIElement that allows apps to observe and interact with the UI elements of other apps. Originally designed for screen readers, it is used by productivity tools like Charm, Raycast, Alfred, and 1Password to access information and take actions across the system.

Why does Charm need Accessibility permissions?

Charm uses AXObserver to watch for text changes across all apps. This is the same mechanism screen readers use to read content aloud. Because Accessibility access grants the ability to read UI elements in other apps, macOS requires explicit user permission. Without it, Charm cannot see text in other apps and cannot make corrections.

Is it safe to give Accessibility access to Charm?

Yes. Charm uses Accessibility access only to read and correct text in real time, entirely on-device. No text is transmitted to any server. Charm is a native macOS app and its Accessibility usage is limited to the text correction function. Many trusted apps including Raycast, Alfred, and 1Password use the same permission for their core features.

Why doesn't autocorrect work in Slack?

Slack is built on Electron, which renders text using Chromium's web engine rather than macOS's native NSTextView. NSSpellChecker only integrates with NSTextView-based text fields. Slack's text fields are web content, so they never connect to NSSpellChecker. Charm solves this by using the Accessibility API, which works regardless of how the host app renders text.

What other apps use the Accessibility API?

Many popular productivity apps use the macOS Accessibility API: Raycast, Alfred, 1Password, BetterTouchTool, and Bartender all require the same Accessibility permission. VoiceOver, Apple's built-in screen reader, is the original and primary use case for the framework.