Fire an alert event to notify accessibility when a permissions bubble gets shown.

ui/views/bubble/bubble_delegate.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/views/bubble/bubble_delegate.h"
 
 #include "ui/accessibility/ax_view_state.h"
 #include "ui/base/resource/resource_bundle.h"
 #include "ui/gfx/color_utils.h"
 #include "ui/gfx/geometry/rect.h"
@@ skipping 287 matching lines @@
 }
 
 void BubbleDelegateView::HandleVisibilityChanged(Widget* widget, bool visible) {
   if (widget == GetWidget() && anchor_widget() &&
       anchor_widget()->GetTopLevelWidget()) {
     if (visible)
       anchor_widget()->GetTopLevelWidget()->DisableInactiveRendering();
     else
       anchor_widget()->GetTopLevelWidget()->EnableInactiveRendering();
   }
+
+  if (widget == GetWidget() && visible) {
+    ui::AXViewState state;
+    GetAccessibleState(&state);
+    if (state.role == ui::AX_ROLE_ALERT_DIALOG)

[msw, 2015/04/06 23:01:20]

Why did you add this condition? Why can't all bubbles be treated similarly?

[David Tseng, 2015/04/06 23:34:02]

Sorry; I should have pinged you on the changes here.

SystemTray happens to be a subclass of this class.

The semantics of an alert currently are as follows:
For ChromeVox, it means compute an utterance by concatenating all of the node's
descendant views as if you navigated to each of them linearly.

For SystemTray, this is undesirable since we really want it to simply read the
name but not all of its descendant views.

Had an offline discussion with dmazzoni@. One option, taken here, is to
explicitly mark all views that are actually alert dialogs as having role alert
dialog and triggering the alert event for alert dialogs only. A different event
should be fired for the "other" cases to distinguish it for clients such as
ChromeVox.

Note that I spent some time exploring other strategies, but due to the
strictness of interactive_ui_tests --gtest_filter=*SpokenFeedbackTests*.*, this
was the minimal change possible without breaking lots of test assumptions.

[msw, 2015/04/07 00:18:22]

What actually toggles the ChromeVox behavior between "an alert" and a non-alert
bubble or dialog? Is it simply the AX_EVENT_ALERT type sent here, the
AX_ROLE_ALERT_DIALOG role, or are both required?

What plans do you have, if any, to audit other bubbles and opt them into the
alert pattern? Can you file a bug with sufficient background/context for someone
else to follow up, if an audit is warranted?

I'm trying to decide how much of this CL is widely applicable to
BubbleDelegateView, or whether it should mostly be limited to
PermissionsBubbleDelegateView.

In either case, the distinction between "alert dialog" and "dialog" behavior is
non-obvious and deserves a comment somewhere.

[David Tseng, 2015/04/07 16:58:06]

Currently, just the alert event.
Done.
crbug.com/474622
The distinction comes from ARIA:
http://www.w3.org/TR/wai-aria/roles#alertdialog

See bug above for a fuller writeup.

+      NotifyAccessibilityEvent(ui::AX_EVENT_ALERT, true);
+  }
 }
 
 }  // namespace views