Since MacViews is not shipping yet, this bug will not reach users yet. Deprioritizing.

Note: I tested on Windows and Chrome OS, which do *not* show the hidden button in the accessibility order.

I'm not sure exactly how windows suppresses it.. But windows does use AXPlatformNodeBAse::GetNext/PreviousSibling where mac does not. I think Mac just traverses the tree built, e.g., by [AXPlatformNodeCocoa AXChildren].

That's populated simply by the vector of child views (i.e. view_->child_count())

int NativeViewAccessibility::GetChildCount() {
  int child_count = view_->child_count();

  std::vector<Widget*> child_widgets;
  PopulateChildWidgetVector(&child_widgets);
  child_count += child_widgets.size();

  return child_count;
}

Perhaps we need to apply some filtering of child Views here, based on visibility?

I think Patti has some investigations into approaches here already. E.g. https://codereview.chromium.org/2119413004/  (dmazzoni: maybe you can have a peek to see if it looks like a suitable direction to take)

There's also an approach here for hiding things from VoiceOver on mac: https://codereview.chromium.org/2478733002/

(tl'dr set NSAccessibilityRoleAttribute to an empty string)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/506491c05a0dd41bc68604c9b34fe56d93705017

commit 506491c05a0dd41bc68604c9b34fe56d93705017
Author: patricialor <patricialor@chromium.org>
Date: Tue Dec 13 23:49:05 2016

MacViews/a11y: Ignore invisible accessibility elements.

BubbleFrameView can optionally show a close button based on the return value of
WidgetDelegate::ShouldShowCloseButton() and overrides. In cases when it is set
to false, the close button still appears in the accessibility tree on Mac.

Fix this by ignoring invisible accessibility elements for macOS only. This fix
is not cross-platform because the ui::AX_STATE_INVISIBLE flag seems to be useful
for Windows and Android accessibility.

BUG= 660230 

Review-Url: https://codereview.chromium.org/2563423006
Cr-Commit-Position: refs/heads/master@{#438342}

[modify] https://crrev.com/506491c05a0dd41bc68604c9b34fe56d93705017/ui/accessibility/platform/ax_platform_node_mac.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/452d2878e6c634245c5757fc0549876e4631722c

commit 452d2878e6c634245c5757fc0549876e4631722c
Author: patricialor <patricialor@chromium.org>
Date: Thu Dec 29 22:48:35 2016

MacViews/a11y: Mark Views as invisible if their parents are invisible.

Currently, only Views returning false from View::visible() will be marked
invisible to a11y clients. This doesn't account for all invisible Views, since
Views which have an invisible ancestor will also be invisible, but still return
true from View::visible(). Account for this when tagging Views invisible for
a11y by switching to View::IsDrawn() instead.

MacViews a11y already ignores invisible Views, so this will fix issues where
a11y clients are seeing invisible controls.

BUG= 657848 ,  660230 
TEST=On Mac, with the #secondary-ui-md flag turned on, open the OIB by clicking
the icon on the left of the URL, then open the collected cookies dialog by
clicking the link under "Cookies", which should read "<X> in use". Turn on
VoiceOver by pressing Cmd+F5 and navigate through the contents of the "Allowed"
tab with VO by pressing Ctrl+Right Arrow. Verify it doesn't read out controls
that belong to the "Blocked" tab.

Review-Url: https://codereview.chromium.org/2601883002
Cr-Commit-Position: refs/heads/master@{#441001}

[modify] https://crrev.com/452d2878e6c634245c5757fc0549876e4631722c/ui/views/accessibility/native_view_accessibility.cc
[modify] https://crrev.com/452d2878e6c634245c5757fc0549876e4631722c/ui/views/accessibility/native_view_accessibility_unittest.cc