Fixed accessibility issues in bookmark bubble dialog.

chrome/browser/ui/views/accessibility/accessibility_event_router_views.cc

Index: chrome/browser/ui/views/accessibility/accessibility_event_router_views.cc
diff --git a/chrome/browser/ui/views/accessibility/accessibility_event_router_views.cc b/chrome/browser/ui/views/accessibility/accessibility_event_router_views.cc
index 25b0feff746b5acf26b8c30aa039d72fa4cf8b99..db7e93c1a0a0d117c30279047516b6b53cd7896e 100644
--- a/chrome/browser/ui/views/accessibility/accessibility_event_router_views.cc
+++ b/chrome/browser/ui/views/accessibility/accessibility_event_router_views.cc
@@ -174,6 +174,7 @@ void AccessibilityEventRouterViews::DispatchAccessibilityEvent(
 
   switch (state.role) {
   case ui::AccessibilityTypes::ROLE_ALERT:
+  case ui::AccessibilityTypes::ROLE_DIALOG:
   case ui::AccessibilityTypes::ROLE_WINDOW:
     SendWindowNotification(view, type, profile);
     break;
@@ -207,6 +208,9 @@ void AccessibilityEventRouterViews::DispatchAccessibilityEvent(
   case ui::AccessibilityTypes::ROLE_SLIDER:
     SendSliderNotification(view, type, profile);
     break;
+  case ui::AccessibilityTypes::ROLE_OUTLINE:
+    // Not used anymore?
+    break;
   default:
     // If this is encountered, please file a bug with the role that wasn't
     // caught so we can add accessibility extension API support.
@@ -395,9 +399,11 @@ std::string AccessibilityEventRouterViews::GetViewContext(views::View* view) {
     // Two cases are handled right now. More could be added in the future
     // depending on how the UI evolves.
 
-    // A control in a toolbar should use the toolbar's accessible name
+    // A control in alert, toolbar or dialog should use the its accessible name
     // as the context.
-    if (state.role == ui::AccessibilityTypes::ROLE_TOOLBAR &&
+    if ((state.role == ui::AccessibilityTypes::ROLE_ALERT ||
+         state.role == ui::AccessibilityTypes::ROLE_DIALOG ||
+         state.role == ui::AccessibilityTypes::ROLE_TOOLBAR) &&

[David Tseng, 2013/11/20 22:13:27]

Did you test this with infobars? It looks like the below block makes a best
guess at the context based on the first static text child view for alerts and
dialogs.

[zel, 2013/11/21 00:19:23]

Well, this statement ensures that if a parent of such UI elements explicitly
defines the context, that's the one we should use instead of drilling through
its children nodes for the first static text. From what I can see in the code,
not many top level view containers (i.e. dialog, alerts) actually override
GetAccessibleState().

         !state.name.empty()) {
       return UTF16ToUTF8(state.name);
     }