a11y: Exclude children of nested keyboard accessible controls from a11y tree.

ui/views/accessibility/native_view_accessibility_unittest.cc

Index: ui/views/accessibility/native_view_accessibility_unittest.cc
diff --git a/ui/views/accessibility/native_view_accessibility_unittest.cc b/ui/views/accessibility/native_view_accessibility_unittest.cc
index c75ae19e1d3ce103c3c77b5b02647d47da023cb0..cfe083ea8fcbaf1a6c307e7655585c3d6db53173 100644
--- a/ui/views/accessibility/native_view_accessibility_unittest.cc
+++ b/ui/views/accessibility/native_view_accessibility_unittest.cc
@@ -70,6 +70,16 @@ class NativeViewAccessibilityTest : public ViewsTestBase {
 
 TEST_F(NativeViewAccessibilityTest, RoleShouldMatch) {
   EXPECT_EQ(ui::AX_ROLE_BUTTON, button_accessibility_->GetData().role);
+#if defined(OS_MACOSX)

[dmazzoni, 2016/11/30 23:12:44]

I'm okay with removing this test or rewriting it to test
something else useful, given this change

[Patti Lor, 2016/12/01 01:12:07]

Will go ahead and do this if it's decided we'll go with a platform independent
approach as per my second comment.

+  // On Mac, the label isn't given a role. Since it's a subview of |button_|
+  // (and the button is focusable), the label is assumed to form part of the
+  // button and not have a role of its own.
+  EXPECT_EQ(ui::AX_ROLE_UNKNOWN, label_accessibility_->GetData().role);
+  // This will happen for all potentially keyboard-focusable Views with
+  // non-keyboard-focusable children, so if we make the button unfocusable, the
+  // label will be allowed to have its own role again.
+  button_->SetFocusBehavior(View::FocusBehavior::NEVER);
+#endif
   EXPECT_EQ(ui::AX_ROLE_STATIC_TEXT, label_accessibility_->GetData().role);
 }