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

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?