Does Eclipse automatically expose accessible roles and states for custom SWT widgets?

Question

When building an Eclipse RCP application with custom SWT widgets, screen readers may announce those controls as generic objects rather than by their intended role or state. The Eclipse Platform maps standard SWT widgets to native accessibility APIs such as Microsoft IAccessible2/UIA on Windows, ATK/AT-SPI on Linux, and macOS accessibility, but custom or owner-drawn controls do not always receive the same automatic treatment.

The unresolved decision is whether Eclipse should provide accessible role, name, state, and focus event exposure for custom widgets by default, or whether RCP developers must explicitly opt in through accessible listener implementations. This choice affects legacy visual behavior, development effort, and assistive-technology consistency across perspectives, wizards, and dialogs. Behavior also varies by Eclipse release, operating system, Java/SWT version, and screen reader, so a single default may not satisfy every platform.

Assuming a current Eclipse Platform release with a custom view containing owner-drawn canvas or composite widgets, is accessible information exposed automatically, or must developers register it manually? Which platform APIs or SWT accessibility hooks determine that default? How can teams verify the actual exposure without relying solely on visual theme settings?

Tasadduq Burney · Answer

Direct answer
No. Eclipse does not automatically expose accessible roles, names, or states for custom SWT widgets such as owner-drawn canvases or composites. Developers must register that information manually through SWT’s Accessible API.
Likely explanation
Standard SWT controls map automatically to native accessibility APIs: IAccessible2/UIA on Windows, ATK/AT-SPI on Linux, and macOS Accessibility. Custom widgets do not receive that default mapping because Eclipse cannot infer intended semantics from visual appearance alone. Without explicit configuration, screen readers announce them as generic objects.
Confirmed facts

Standard widgets such as Button, Label, Table, and Tree receive automatic accessibility mapping through SWT’s Accessible interface.
Custom owner-drawn composites and canvases receive no automatic role, name, or state exposure.
SWT provides createAccessible(), AccessibleAdapter, setAccessibleRole(), setAccessibleName(), and setAccessibleState() as the platform-independent hooks.
The OS bridge converts the configured SWT Accessible data into native IAccessible2, AT-SPI, or UIA objects.

Steps to verify exposure

Open the OS accessibility inspector: Inspect.exe on Windows, Accerciser on Linux, or Accessibility Inspector on macOS.
Inspect the custom widget and confirm its role, name, state, and value are not generic "object" or "unknown".
Call widget.getAccessible().getRole(), getName(), and getState() at runtime and log or assert the returned values.
Test with a screen reader such as NVDA, VoiceOver, or Orca to confirm the intended announcement.

What may change the recommendation
Provide the exact Eclipse Platform version, SWT version, and operating system if you need to confirm whether a specific release changes the default behavior for custom widgets.

Does Eclipse automatically expose accessible roles and states for custom SWT widgets?

1 answer

Direct answer

Likely explanation

Confirmed facts

Steps to verify exposure

What may change the recommendation

Your perspective belongs here.

0 question comments