SWT Widgets ↔ Eclipse Workbench: What is the optimal strategy to expose ARIA labels for custom views?

Answer: Use SWT Accessible via AccessibleAdapter and register it through the Eclipse Accessibility Framework.

Confirmed facts

• SWT provides an Accessible API that maps to native OS accessibility layers (UI Automation, AXAPI, AT-SPI).
• Overriding getName and getDescription on an AccessibleAdapter supplies the ARIA‑like label and description.
• The Eclipse Accessibility Framework consumes contributors registered at the org.eclipse.accessibility.accessibleProvider extension point (or via the e4 UI model).
• For composite widgets, setting the container’s accessible name or aggregating child accessible objects yields a logical group label and proper tab order.

Steps needed for this case

1. Create an AccessibleAdapter for each custom control (or the view’s root composite). Override getName to return the desired ARIA label and getDescription for additional context.
2. Attach the adapter to the control using control.getAccessible().addListener(...) or, more simply, new AccessibleAdapter(control) { ... }.
3. Register the provider via plugin.xml:

   <extension
         point="org.eclipse.accessibility.accessibleProvider">
         <provider
           class="com.example.myview.MyViewAccessibleProvider">
         </provider>
       </extension>

   In the provider class, return the adapted control’s accessible object when queried.
4. Handle composites: if the view contains multiple related widgets, set the accessible name on the parent composite (e.g., parent.getAccessible().addListener(...)) to describe the group, and ensure child controls retain their own labels for fine‑grained navigation.
5. Verify using Eclipse’s Accessibility Tools (Accessibility View, aXe core) or platform inspectors (Inspect on Windows, Accessibility Inspector on macOS) to confirm the exposed name, description, and role.