Accessibility support in CEF1

[gusverdun]

Has anyone taken a look at what it would take to implement support for this?

Any pointers would be appreciated.

Thanks,

Gus

[magreenblatt]

What features or APIs do you mean specifically?

[gusverdun]

I need screen-reader support via MSAA and VoiceOver as described here:

http://www.chromium.org/developers/acce ... essibility
http://www.chromium.org/developers/acce ... essibility

[gusverdun]

So, starting with CEF3, I was able to get AViewer to read the HTML with the following steps:

• regsvr32 (in admin mode) IAccessible2Proxy.Dll from AViewer (to test the IAccessible2 info)
• Apply this patch:
  
  

  Code: Select all

  Index: content/browser/accessibility/browser_accessibility_win.cc
===================================================================
--- content/browser/accessibility/browser_accessibility_win.cc   (revision 153668)
+++ content/browser/accessibility/browser_accessibility_win.cc   (working copy)
@@ -2417,7 +2417,7 @@
   if (!node)
     return E_INVALIDARG;
 
-  *node = parent_->ToBrowserAccessibilityWin()->NewReference();
+  *node = parent_ ? parent_->ToBrowserAccessibilityWin()->NewReference() : NULL;
   return S_OK;
 }

There is more work to be done to get the standard menu bar and navigation controls to announce when in focus, however this shows that the content layer is doing all the heavy lifting.

[magreenblatt]

I wonder why this patch is necessary. Does Chrome always initialize |parent_|? Perhaps we should do the same in CEF?

[gusverdun]

Actually the menu item and buttons get read out loud by the "narrator" so that part is working, which is what I expected.

As I don't have a real screen-reader running, I had to force Chromium to publish this info via the command line:

-force-renderer-accessibility

[gusverdun]

I wondered about |parent_| too. Other methods in that class check the pointer before referencing it. The header file says null means root object.

It could be that the AViewer tool I am using asks for the parent node from the root when no other tool does that. Still, should be guarded.

On another note, the code does respond when asked for the IAccessible2 interface even when an IAccessible2 proxy is not available. This causes the code to crash later on in the OLE/RPC layer. In this scenario, who is responsible for ensuring such a proxy exists? I'd expect that the client (AViewer) should be the checking it, but the crash happens on the server (cefclient) side. So, perhaps the server side should also check and thus not support IAccessible2 if no proxy is found.

[magreenblatt]

These sound like bugs that should be filed with Chromium since they occur in the Content API.

[gusverdun]

Agreed.

Also found out that the Mac support is working with the forced flag only.

The code for screen reader detection is in the src/chrome/browser level rather than the content level.

Perhaps this function in http://src.chromium.org/viewvc/chrome/t ... iew=markup needs to be in CEF?

Code: Select all

- (void)accessibilitySetValue:(id)value forAttribute:(NSString*)attribute {
  if ([attribute isEqualToString:@"AXEnhancedUserInterface"] &&
      [value intValue] == 1) {
    BrowserAccessibilityState::GetInstance()->OnScreenReaderDetected();
    for (TabContentsIterator it;
         !it.done();
         ++it) {
      if (TabContents* contents = *it) {
        if (content::RenderViewHost* rvh =
                contents->web_contents()->GetRenderViewHost()) {
          rvh->EnableFullAccessibilityMode();
        }
      }
    }
  }
  return [super accessibilitySetValue:value forAttribute:attribute];
}


I will post bug id's once I have them.

[magreenblatt]

Looks like the NSApplication instance needs to implement the NSAccessibility protocol. Since we let the client provide their own NSApplication implementation we should probably add a CefScreenReaderDetected() function that the client can call from accessibilitySetValue: to perform the necessary work. Please add an issue for this to the CEF issue tracker.