Vixen
dd8b0a81
csharp
public static class MacOSAccessibility

Which accessibility settings macOS is running with.

Read the guide page for this →

Remarks

com.apple.universalaccess in NSUserDefaults, and not NSWorkspace.accessibilityDisplayShouldReduceMotion. The two agree, and only one of them is reachable from a process that never made an NSApplication — which is every SDL application, this engine's included. It is the same choice MacOSAppearance makes and for the same reason: Foundation answers, and NSWorkspace.sharedWorkspace is one of the AppKit singletons that does not.

⚠ "AppKit wants an application object" is the general rule true of this class and not of AppKit, and the difference was measured on 2026-09-06. NSColor's semantic colours — labelColor, controlAccentColor and the rest — resolve perfectly well with NSApp nil, follow the system appearance, and follow +[NSAppearance setCurrentAppearance:] on a secondary thread. So the sentence above is a fact about the two singletons this file and MacOSAppearance would otherwise have used, and it must not be read as a reason the platform's palette cannot be read at all — it was, in two other files, and they were wrong.

⚠ An absent key is false, not unknown. These defaults are written when the setting is turned on and the domain simply has no entry until then — so reaching the domain and finding nothing in it is a genuine "the user has not asked for this", the same way AppleInterfaceStyle's absence is genuinely light. What is unknown is failing to reach the Objective-C runtime at all.

⚠ increaseContrast and not reduceTransparency. The two sit next to each other on the same settings pane and only the first is what forced-colors describes — macOS's Reduce Transparency changes materials, not the palette, and reporting it as a forced-colours mode would make a stylesheet throw away its own colours because somebody turned off a blur.

⚠ TextScale is left null here and there is nothing to write instead. macOS has no system-wide text scale: Dynamic Type is a UIKit API and the Mac's equivalents are per-application (a font size in each app's own preferences) or a display-resolution change, neither of which is a multiplier an application can read. So "no source" is the honest answer, and it is the same null-is-not-1.0 reading the two flags below already carry — Windows and GNOME both answer this and macOS does not, which is a difference between platforms rather than a hole in this file.

Methods (1)

Used by (1)

  • DesktopAccessibilityVixen.Platform.Desktop