SDL accessibility events: should SDL synthesize focus changes, or should the app map them?

Question

ContextI'm building an SDL2-based UI layer that must work with screen readers on Windows, macOS, and X11. SDL_PollEvent gives me raw input and window events, but no accessibility metadata, so I currently translate SDL_WINDOWEVENT_FOCUS_GAINED and my own widget focus model into platform accessibility API calls (UI Automation, NSAccessibility, AT-SPI) myself.The decisionSDL 2.0.9 added SDL_HINT_ACCESSIBILITY_FOCUS for focus tracking, but its behavior appears to differ per platform, and I'm unsure how much of the focus-change story SDL is expected to own. I see two documented approaches:Rely on SDL's hint-driven focus tracking and treat window focus events as the single source of truth, mapping them one-to-one to accessibility focus events.Keep SDL purely as an input source and synthesize all accessibility focus/role announcements in the application layer, per platform.A complicating constraint: on Windows with high-DPI scaling, event coordinates can be compressed or expanded, so any hit-testing for focus rectangles seems to require SDL_GetWindowDisplayDPI before computing accessible bounds.QuestionsIs SDL_HINT_ACCESSIBILITY_FOCUS intended to be sufficient for cross-platform focus announcement, or is it only a partial helper that still requires per-platform app code?Where should DPI correction happen so accessible bounds match what SDL reports in event coordinates?Is there a documented position on SDL ever synthesizing accessibility events itself, or is that explicitly out of scope?

Tasadduq Burney · Answer

AnswerThe SDL_HINT_ACCESSIBILITY_FOCUS flag only enables SDL to emit SDL_WINDOWEVENT_FOCUS_GAINED/LOST events; it does not synthesize full platform accessibility events, so the application must still map those events to UI Automation, NSAccessibility, or AT‑SPI.Confirmed factsSDL 2.0.9 introduced SDL_HINT_ACCESSIBILITY_FOCUS to track focus changes.SDL generates focus events but does not create platform‑specific accessibility API objects.SDL_GetWindowDisplayDPI (available from SDL ≥ 2.0.12) is required to compute accessible bounds under high‑DPI scaling on Windows.SDL maintainers have stated that synthesizing accessibility events is out of scope; SDL’s responsibility ends at input and window management.Likely explanationBecause the hint is platform‑dependent and its reliability varies, treating SDL focus events as the single source of truth for accessibility compliance is risky. The recommended approach is to keep SDL as the input source, enable the hint for basic focus tracking, and then synthesize the required accessibility announcements in the app layer, applying DPI correction before converting event coordinates to accessible rectangle bounds.Steps for this caseEnable SDL_HINT_ACCESSIBILITY_FOCUS before creating the window (e.g., SDL_SetHint(SDL_HINT_ACCESSIBILITY_FOCUS, '1')).If you run on Windows with DPI scaling higher than 100 %, query the window’s DPI factor: float dpi = SDL_GetWindowDisplayDPI(window); (requires SDL ≥ 2.0.12).Compute the accessible rectangle’s logical size by multiplying SDL_GetWindowDisplayDPI() with the event’s x and y coordinates, then adjust the width and height accordingly.Map the focus‑gained event to the appropriate platform API (UI Automation on Windows, NSAccessibility on macOS, AT‑SPI on X11) using the corrected bounds.Missing diagnostic detailPlease confirm the SDL version you are using (or whether SDL_GetWindowDisplayDPI is available), as this determines whether DPI correction must be applied.

SDL accessibility events: should SDL synthesize focus changes, or should the app map them?

Context

The decision

Questions

1 answer

Answer

Confirmed facts

Likely explanation

Steps for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments