We have spent a great deal of effort on supporting accessibility APIs on both Windows and OSX, unfortunately it is a very difficult challenge due to extremely poor documentation, on both sides. If anybody has any good resources that may be of help on the code side for supporting this, we would be happy to take a look and spend more time improving support for these APIs.

I'm one of the two lead developers of the NVDA screen reader for Windows. I appreciate the effort to support accessibility so far. While I certainly agree some of the documentation could be easier to find or follow, I think the available documentation does cover a lot of major points that aren't implemented here. Regardless, here's a quick summary of some major problems (some well covered by documentation, some not) that would make things a lot better if they were fixed.

• On Reaper's root accessibility objects (with ROLE_SYSTEM_GROUPING), IAccessible::accParent currently returns NULL. It should return the oleacc window object for this HWND; i.e. AccessibleObjectFromWindow with the HWND and OBJID_WINDOW.
• IAccessible::accNavigate is not implemented. Although MSDN says it is deprecated, it is still used by NVDA and probably other clients. (There are good reasons I believe this shouldn't be deprecated at all.) It'd be great if support for NAVDIR_FIRSTCHILD, NAVDIR_NEXT and NAVDIR_PREVIOUS could be implemented.
• IAccessible::accDefaultAction and IAccessible::accDoDefaultAction are not implemented. For controls which can be activated, these should activate the control. accDefaultAction could return a name like "activate", "click" or "press".
• The faders don't expose a value. It'd probably make sense for these to expose the textual value via IAccessible::accValue.
• The grouping accessibles should expose a useful name where possible; e.g. the track number and name for tracks. Also, some of the groupings seem to be toolbars. They should ideally expose ROLE_SYSTEM_TOOLBAR.
• At present, without specific code (and assuming Reaper even fires accessibility events), a screen reader or other assistive technology (AT) product doesn't know what changes to report to the user. One simple option is to pretend (as far as accessibiliy is concerned) that any control that is manually adjusted/activated by the user (e.g. via keyboard or mouse) receives the focus. This includes the track accessible (ROLE_SYSTEM_GROUPING) when a track becomes the current track. This is controversial because it doesn't really have focus, but it does tell the user exactly what they need to know. To do this, you'll need to fire EVENT_OBJECT_FOCUS using NotifyWinEvent and expose STATE_SYSTEM_FOCUSED via IAccessible::accState on the control with "fake" focus. You'll also need to implement IAccessible::accFocus. If the control already has the fake focus (e.g. multiple contiguous changes to the same control), it shouldn't get focus again, but an event needs to be fired indicating that the control changed; e.g. EVENT_OBJECT_VALUECHANGE if the value changed or EVENT_OBJECT_STATECHANGE if the state changed.
• Regarding toggles such as mute and solo, it might be better to always expose the names as "Mute", "Solo", etc., give them ROLE_SYSTEM_CHECKBOX and expose STATE_SYSTEM_CHECKED when they're enabled. Currently, the name changes depending on the state; e.g. "Unmute track" when the trakc is muted. This could get confusing particularly if the above focus idea is implemented.
• Unless I'm missing something, I don't think there is any accessibility information exposed for items.
• IAccessible::accLocation and IAccessible::accHitTest need to deal in physical screen coordinates. Because Reaper doesn't seem to be DPI aware, it's currently using the coordinates it gets internally, but these are logical, not physical. These need to be converted with LogicalToPhysicalPointForPerMonitorDPI/LogicalToPhysicalPoint and vice versa. (Annoyingly, you'll have to use the *ForPerMonitorDPI functions on Windows >= 8 and the older versions without this suffix on Windows < 8.)

This is far from complete, but it should be a good start.

In addition, it's important that the various context menus are accessible from the keyboard. If I make a track current with the keyboard, the Applications key doesn't seem to do anything unless I click in the track first. Also, I believe there are multiple context menus. The solution implemented by ReaAccess was to use modifiers and the Applications key for other context menus; e.g. control+Applications.

Note that I was originally suggesting that Reaper just fakes the focus for accessibility. However, it'd certainly be better if focus were more "real" in some cases (such as items) so that keys like the Applications key are truly context sensitive as @Scottsdale suggests.